Root Cause is Plural

В devops культуре в случае возникновения серьезного инцидента принято описывать post-mortem - документ, описывающий причины возникновения инцидента, хронологию и действия, которые необходимо предпринять чтобы не допустить повторения инцидента в будущем

Обычно в этих документах ищется корневая причина - root cause. Таким образом предполагается, что есть какая-то одна, главная причина, полечив которую можно исправить множество проблем. В аналогии с земледелием (а корневая причина это именно оно и есть) существует небольшая несостыковка - у всех растений нет единого корня, корни - это почти всегда достаточно развесистая система.

В рамках разбора инцидентов также необходимо не искать одну, главную корневую причину, а строить дерево из эффектов и причин, после чего принимать решение об исправлении проблем.

Чтобы построить такое дерево достаточно использовать обычные практики для обсуждения post-mortem'ов:

1. Задавать вопросы 5W
1.1. What heppened (Что случилось)?
1.2. Where did it happen (Где случилось)?
1.3. Who was impacted by incident (На кого повлияло)?
1.4. Where did problem and resolution events occur (Когда случилось)?
1.5. Why did the incident occur (Почему это случилось)?
2. Для каждой найденной причины и эффекта спрашивать Why (почему), пока мы не достигнем причины, на которую повлиять не можем или на которую влиять слишком дорого.
3. Построить дерево причин и эффектов, проанализировать его и придумать действия, выполнение которых покроет как можно большее количество ветвей дерева

https://codywilbourn.com/2018/01/02/root-cause-is-plural/

#development #postMortems #devops #recommended

Blogged Answers: My Experience Modernizing Packages to ESM

Статья от мейнтенера популярных npm-пакетов (redux) про боль переезд на ES-модули. Казалось бы, модули появились еще в 2015 году и сейчас переезжать на них должно быть достаточно легко. Однако, на деле это достаточно нетривиальная задача.

В статье автор описывает кучу проблем, с которыми он боролся во время переезда с commonJS на ESM. Чтобы перевести пакеты на ESM, необходимо иметь очень хорошие знания о том, как ведет себя различный тулинг. Поэтому автор часто консультировался с мейнтейнерами других пакетов и разработчиками TS. Кое-где даже пришлось заменить тулинг, например, переехать с jest на vitest.

Очень хорошая статья с кучей ссылок и проблем. Рекомендую к прочтению, если у вас есть свои open source пакеты или вы разрабатываете внутренний инструментарий в компании и поставляете его через npm-пакеты

https://blog.isquaredsoftware.com/2023/08/esm-modernization-lessons/

#development #javascript #esmodules #recommended

npmgraph - Visualize npm Module Dependencies

npmgraph - тулинг для визуализации завимостей npm-пакетов. Позволяет посмотреть на дерево зависимостей конкретного package.json

https://npmgraph.js.org

#development #javascript #npm

A compilation of outstanding testing articles (with JavaScript)

Подборка статей про автоматическое тестирование от консультанта в этой сфере. Подборка содержит 10 статей, обязательных к прочтению (по мнению автора) + 10 ссылок на полезные материалы

Список статей весьма хороший. Часть из них я уже читал (и вероятно они даже есть где-то в этом канале), часть, видимо, прочту в скором времени

Рекомендую к ознакомлению

https://practica.dev/blog/a-compilation-of-outstanding-testing-articles-with-javaScript/

#development #javascript #testing #recommended

Как я вошёл в клуб бага 323

Перевод статьи о достаточно интересном баге. Баги встречаются практически везде, но чаще всего в коде приложения. Чуть реже в тулинге - такие баги можно искать, но бывает просто. Но одни из самых сложных багов - связанные с железом или чем-то близким к нему (драйвера например).

В статье автор как раз сталкивается с таким видом бага - программа начинает по разному сравнивать числа, в зависимости от разрядности сборки и включенных флагов оптимизации. Удивительное и достаточно короткое и интересное погружение в исследование багов на очень низком уровне

https://habr.com/ru/articles/754730/

#development #bug #compiler #cpu

Дайджест за 2023-08-14 - 2023-08-18

⭐Root Cause is Plural
В devops культуре в случае возникновения серьезного инцидента принято описывать post-mortem - документ, описывающий причины возникновения инцидента, хронологию и действия, которые необходимо предпринять чтобы не допустить повторения инцидента в будущем

Обычно в этих документах ищется корневая причина - root cause. Таким образом предполагается, что есть какая-то одна, главная причина, полечив которую можно исправить множество проблем. В аналогии с земледелием (а корневая причина это именно оно и есть) существует небольшая несостыковка - у всех растений нет единого корня, корни - это почти всегда достаточно развесистая система.

⭐Blogged Answers: My Experience Modernizing Packages to ESM
Статья от мейнтенера популярных npm-пакетов (redux) про боль переезд на ES-модули. Казалось бы, модули появились еще в 2015 году и сейчас переезжать на них должно быть достаточно легко. Однако, на деле это достаточно нетривиальная задача.

В статье автор описывает кучу проблем, с которыми он боролся во время переезда с commonJS на ESM. Чтобы перевести пакеты на ESM, необходимо иметь очень хорошие знания о том, как ведет себя различный тулинг. Поэтому автор часто консультировался с мейнтейнерами других пакетов и разработчиками TS. Кое-где даже пришлось заменить тулинг, например, переехать с jest на vitest.

npmgraph - Visualize npm Module Dependencies
npmgraph - тулинг для визуализации завимостей npm-пакетов. Позволяет посмотреть на дерево зависимостей конкретного package.json



⭐A compilation of outstanding testing articles (with JavaScript)
Подборка статей про автоматическое тестирование от консультанта в этой сфере. Подборка содержит 10 статей, обязательных к прочтению (по мнению автора) + 10 ссылок на полезные материалы

Список статей весьма хороший. Часть из них я уже читал (и вероятно они даже есть где-то в этом канале), часть, видимо, прочту в скором времени

Как я вошёл в клуб бага 323
Перевод статьи о достаточно интересном баге. Баги встречаются практически везде, но чаще всего в коде приложения. Чуть реже в тулинге - такие баги можно искать, но бывает просто. Но одни из самых сложных багов - связанные с железом или чем-то близким к нему (драйвера например).

В статье автор как раз сталкивается с таким видом бага - программа начинает по разному сравнивать числа, в зависимости от разрядности сборки и включенных флагов оптимизации. Удивительное и достаточно короткое и интересное погружение в исследование багов на очень низком уровне

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

How we reduced the size of our JavaScript bundles by 33%

Статья от команды Dropbox о том, как они сменили бандлер и уменьшили размер JS статики на треть.

Dropbox - крупная компания со своими сложными вызовами и поэтому, в 2014 году они сделали свой бандлер и свою технологию Dropbox Web Server (DWS). DWS позволяет делать модульный веб - страница состоит из независимых страничных блоков (pagelet), которые разрабатываются и обрабатываются независимо друг от друга.

Кастомный бандлер сильно отстал от лидеров рынка и поэтому было принято решение переезжать на современные решения. Самые крупные проблемы предыдущей архитектуры:

1. Дублирующийся код. Т.к. pagelet-ы независимы друг от друга, то если у них есть общий код, то они его встраивают в себя, вместо того чтобы переиспользовать
2. Отсутствие автоматического код-сплиттинга. Бандлер поддерживал его, но только через ручной конфиг на 6000 строк
3. Отсутствие три-шейкинга

Все эти проблемы давно решены текущими сборщиками, но не были решены в самописном решении. Dropbox переехал на использование rollup, но при этом миграция на него была плавная: сначала только dev сборка, затем только для сотрудников, затем раскатка на пользователей.

Во время плавной миграции были следующие трудности:

1. Иногда rollup падал из-за высокого потребления памяти в CI
2. Сложно поддерживать одновременно 2 бандлера
3. Появились баги из-за слишком агрессивного три-шейкинга у Rollup
4. Rollup включал strict mode для кода, что ломало некоторые зависимости

Как результат:

1. Удалось уменьшить JS статику на 33%
2. Количество JS файлов уменьшилось на 15%
3. Улучшился TTVC (time to visual complete). Я так понял это одна из основных метрик, за которыми следит dropbox

https://dropbox.tech/frontend/how-we-reduced-the-size-of-our-javascript-bundles-by-33-percent

#development #javascript #performance #dropbox #bundler #rollup

You-Dont-Need-Lodash-Underscore

Githu-репозиторий, который объясняет, что современный JS достаточно богат методами и синтаксисом, чтобы не использовать lodash вообще. Для каждого lodash метода приводятся 1 или несколько сниппетов кода на нативном JS, который выполняет аналогичную задачу и минимальные версии браузеров с поддержкой этого кода. Также, кроме понятных объяснений, предоставляется eslint плагин, который, наверное, делает автозамену вызовов lodash на нативный код.

В целом, ничего нового, но хорошо визуализировано и автоматизировано eslint'ом. Некоторые сниппеты кода на нативном JS вызывают улыбку. Например, аналоги _.get и _.chunk. Очень интересно было бы посмотреть потребления памяти и перформанс некоторых аналогов

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

#development #javascript #lodash

Discover three.js

Большая веб-книжка про three.js. Если вы хотели научится делать супер анимации с помощью three.js, то эта книжка для вас

https://discoverthreejs.com

#development #javascript #threejs #book

What's New in DevTools (Chrome 117) - Chrome Developers

Выходит 117 Google Chrome. Я обычно не пишу о релизах браузеров т.к. там редко бывает что-то прям такое важное и новое. Но в этом релизе добавляют 2 возможности, которых очень давно нам не хватало: возможность кастомизировать ответ сервера (и контент и заголовки). Наконец-то не нужно парится со всякими тулзами, чтобы сделать MITM самому себе (прокси, расширения, либы). Это теперь встроено в браузер. Также из интересных для меня фичей, в нетворке можно будет отключить запросы расширений

https://developer.chrome.com/blog/new-in-devtools-117/

#development #releaseNotes #googleChrome

Дайджест за 2023-08-21 - 2023-08-24

How we reduced the size of our JavaScript bundles by 33%
Статья от команды Dropbox о том, как они сменили бандлер и уменьшили размер JS статики на треть.

Dropbox - крупная компания со своими сложными вызовами и поэтому, в 2014 году они сделали свой бандлер и свою технологию Dropbox Web Server (DWS). DWS позволяет делать модульный веб - страница состоит из независимых страничных блоков (pagelet), которые разрабатываются и обрабатываются независимо друг от друга.

You-Dont-Need-Lodash-Underscore
Githu-репозиторий, который объясняет, что современный JS достаточно богат методами и синтаксисом, чтобы не использовать lodash вообще. Для каждого lodash метода приводятся 1 или несколько сниппетов кода на нативном JS, который выполняет аналогичную задачу и минимальные версии браузеров с поддержкой этого кода. Также, кроме понятных объяснений, предоставляется eslint плагин, который, наверное, делает автозамену вызовов lodash на нативный код.

В целом, ничего нового, но хорошо визуализировано и автоматизировано eslint'ом. Некоторые сниппеты кода на нативном JS вызывают улыбку. Например, аналоги _.get и _.chunk. Очень интересно было бы посмотреть потребления памяти и перформанс некоторых аналогов

Discover three.js
Большая веб-книжка про three.js. Если вы хотели научится делать супер анимации с помощью three.js, то эта книжка для вас


What's New in DevTools (Chrome 117) - Chrome Developers
Выходит 117 Google Chrome. Я обычно не пишу о релизах браузеров т.к. там редко бывает что-то прям такое важное и новое. Но в этом релизе добавляют 2 возможности, которых очень давно нам не хватало: возможность кастомизировать ответ сервера (и контент и заголовки). Наконец-то не нужно парится со всякими тулзами, чтобы сделать MITM самому себе (прокси, расширения, либы). Это теперь встроено в браузер. Также из интересных для меня фичей, в нетворке можно будет отключить запросы расширений


——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Use web components for what they’re good at

Статья, защищающая веб-компоненты, написанная ответ на другую статью про то, что веб-компоненты непопулярны

В целом статья примерно про то же самое, но фокусируется не на том, что веб-компоненты плохи, а на том, где их лучше использовать

Первый хороший кейс, это компоненты, которые имеют смысл только в браузере (виджет выбора дат в календаре или выбор эможи)

Второй хороший кейс - это использовать веб-компоненты как механизм для миграции. Например, с одного фреймворка на другой. Большинство фреймворков поддерживают веб-компоненты, а значит, если мы решили переехать с фреймворка А на фреймворк Б, мы можем завернуть компоненты реализованные на фреймворке Б в веб-компоненты и начать использовать их в фреймворке А, без построения своих бриджей и адаптеров.

Третий хороший кейс - это крупные компании и дизайн системы. Автор говорит, что по некоторым замерам, веб-компоненты в интернете встречаются намного чаще, чем React. Это готовые дизайн-системы на веб-компоненты и крупные компании типа Oracle, IBM, Adobe и другие . Они используют web-component'ы потому что они работают почти везде и их легко подключать: никаких бандлеров и транспайлеров, просто вставь html тэг и скрипт и все заработает

Вывод: у веб-компонентов определенно есть проблемы, но то что это вообще стандартизуется - это хорошо. Нет четкого ответа, кому и когда стоит использовать веб-компоненты в 2023 году. Но есть кейсы, где они хороши

https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/

#development #webcomponents

Как показать миллион зданий на карте — и не сломать браузер

Статья от 2ГИС про то, как разные агрегации по миллионам объектам на карте. 2ГИС часто радует своими статьями с интересными высоконагруженными кейсами, и эта статья - не исключение, хотя коротковата

В статье рассказывается, как можно обрабатывать огромные массивы данных в браузере. Если коротко, то решение 2ГИС в использовании следующих инструментов: WebWorkers, передача данных в бинарном виде, обработка на GPU

https://habr.com/ru/companies/2gis/articles/755620/

#development #javascript #performance #recommended

Сейчас будет поcт про вакансию в проекте, где я работаю, поэтому если вам такой контент неинтересен - просто пролистайте его.

———————————————————————

Всем привет! Я работаю в Тинькофф.Путешествиях и у нас есть крутая вакансия - нам нужен крутой техлид фронтенда.

Немного про проект: мы разрабатываем сервис для путешествий в рамках Тинькофф. Помогаем людям путешествовать (покупать авиа и жд билеты, бронировать отели, покупать туры) с крутым UX, техподдержкой и кэшбеком. Делаем с любовью, используя React + Typescript, на фреймворке tramvai (один из мейнтейнеров ведет свой канал), пишем много автотестов разного уровня, проводим внутренние митапы

Почему у нас круто (лично по моему мнению, это пункты, почему мне нравится работать в Тинькофф и в Путешествиях в частности):
- Крутая инженерная культура. Пишем автотесты, автоматизируем рутину и мониторинг, прокачиваем SRE-скилы, выступаем на конференциях и митапах.
- Мы постоянно обмениваемся знаниями. Внутри Тинькофф есть куча разных митапов по разным темам. Но также внутри Путешествий есть свои регулярные митапы, где разработчики (и не только) рассказывают про всякие прикольные штуки, с которыми они столкнулись в своей работе. Например, на последней встрече один из разработчиков рассказывал про реальный кейс, когда React проставлял атрибут lazy у картинок с запозданием, что привело к деградации производительности для пользователя. Он рассказал почему так случилось, какие гипотезы у нас были для решения этой проблемы и как каждое решение афектит на пользовательские метрики.
- Мы делаем продукт, который полезен людям. У нас есть интересные случаи, когда мы помогали людям решить проблемы например с авиакомпаниями, которые тяжело решить не через нас
- Внутри Тинькофф есть реально крутые разработчики, которые делают крутые вещи и у которых есть чему научиться

Кого мы ищем:
Мы ищем человека который:
- является крутым технарём: умеет и в frontend, и в инфраструктуру и работать с неизвестным (или новым) кодом и в хорошие технические практики
- Имеет лидерские качества и базовые организаторские способности
- готов развивать культуру разработки
- следить за техническим развитием проекта и выплатой технического долга

Если вас заинтересовала эта вакансия или у вас есть вопросы, пишите мне в личку @crazymax101, я отвечу

Также у нас в Тинькофф.Путешествиях есть вакансии просто на фронтенд-разработчиков, QA, C#, GoLang, Scala.
Ну и в целом есть вакансии вообще на любой стек в Тинькофф 🙂
Если вам стало интересно, также пишите мне в личку @crazymax101

А еще 9го сентября я буду выступать в Томске на конференции Город IT. Буду рассказывать про код-ревью. Приходите 🙂
https://gorod.it/inprog?fact_id=19551

On React Suspense’s throttling

Статья объясняет проблему тротлинга рендера при вложенных Suspense. Не уверен что это корректно называть тротлингом, но сама проблема интересна.

Представьте, что у вас есть вложенные Suspense. React работает так, что если первый Suspense ушел в ожидание раньше, чем рендер дошел до вложенного Suspense, то как следствие когда promise, подвесивший первый Suspense выйдет из ожидания, рендер дойдет до второго Suspense и мы бы ожидали увидеть контент первого Suspense и fallback у второго. Но на практике наблюдается некоторое время, когда мы видим состояние fallback первого Suspense. Так происходит потому что React умный и не комитит изменения Virtual DOM сразу в DOM, а ждет некоторое время. Из-за чего появляется задержка, когда мы бы могли уже показать пользователю контент, но этого не происходит.

В принципе, ничего криминального React не делает, но факт интересный

https://andreigatej.dev/blog/on-react-suspense-throttling/

#development #react #suspense #performance

React Suspense in three different architectures

Статья рассматривает как React Suspense в React 18 влияет на приложение в трех разных архитектурах: клиентский рендер, серверный рендер и серверные компоненты.

При клиентском рендере есть 2 ключевых юзкейса для Suspense: загрузка больших компонентов и загрузка данных

Если для работы страницы нужен большой кусок кода (компонент + его логика), то имеет смысл выделить это в отдельный чанк и ждать его загрузки. Один из простых способов это сделать - это скомбинировать Suspense и React.lazy

Про загрузку данных не буду особо пояснять, это кажется самый базовый кейс для Suspense

При серверном рендере, Suspense позволяет гидрировать разные части приложения в разные моменты времени. При этом React принимает решение о том, что именно гидрировать, на основе действий пользователям (если блок уже понадобился пользователю - значит пора это гидрировать)

При серверных компонентах Suspense позволяет отдавать готовый HTML сразу, а то что ожидается в Suspense догружать позже по готовности контента. Этакий стриминг контента на новых рельсах.

https://elanmed.dev/blog/suspense-in-different-architectures

#development #react #suspense #recommended

Дайджест за 2023-08-28 - 2023-08-31

Use web components for what they’re good at
Статья, защищающая веб-компоненты, написанная ответ на другую статью про то, что веб-компоненты непопулярны

В целом статья примерно про то же самое, но фокусируется не на том, что веб-компоненты плохи, а на том, где их лучше использовать

⭐Как показать миллион зданий на карте — и не сломать браузер
Статья от 2ГИС про то, как разные агрегации по миллионам объектам на карте. 2ГИС часто радует своими статьями с интересными высоконагруженными кейсами, и эта статья - не исключение, хотя коротковата

В статье рассказывается, как можно обрабатывать огромные массивы данных в браузере. Если коротко, то решение 2ГИС в использовании следующих инструментов: WebWorkers, передача данных в бинарном виде, обработка на GPU

On React Suspense’s throttling
Статья объясняет проблему тротлинга рендера при вложенных Suspense. Не уверен что это корректно называть тротлингом, но сама проблема интересна.

Представьте, что у вас есть вложенные Suspense. React работает так, что если первый Suspense ушел в ожидание раньше, чем рендер дошел до вложенного Suspense, то как следствие когда promise, подвесивший первый Suspense выйдет из ожидания, рендер дойдет до второго Suspense и мы бы ожидали увидеть контент первого Suspense и fallback у второго. Но на практике наблюдается некоторое время, когда мы видим состояние fallback первого Suspense. Так происходит потому что React умный и не комитит изменения Virtual DOM сразу в DOM, а ждет некоторое время. Из-за чего появляется задержка, когда мы бы могли уже показать пользователю контент, но этого не происходит.

⭐React Suspense in three different architectures
Статья рассматривает как React Suspense в React 18 влияет на приложение в трех разных архитектурах: клиентский рендер, серверный рендер и серверные компоненты.

При клиентском рендере есть 2 ключевых юзкейса для Suspense: загрузка больших компонентов и загрузка данных

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

The complexity of writing an efficient NodeJS Docker image

Хороший гайд про создание оптимизированного докер-образа для nodejs приложения. Докер образа построены на слоях - т.е. каждая команда в нем создает отдельный слой, который затем может кешироваться. При скачивании образа, где оптимизации не были применены, мы можем скачать много "лишних" слоев

В этом гайде шаг за шагом показано, как использовать особенности работы Docker себе во благо. Автор добивается ускорения сборки новой версии образа в 43% без кеша и 73% с кешом, а также уменьшения размера образа в 5 раз.

Примененные оптимизации:

1. Взять оптимизированный base для образа. Автор берет nodejs-slim, т.к. alpine хоть и меньше, несет с собой musl вместо glibc, из-за чего могут наблюдаться ошибки в работе кода
2. Использовать dockerignore
3. Использовать multi-stage сборку. Автор использует 3 стейджа.
4. Не устанавливать или удалять dev и некоторые другие "лишние" зависимости
5. Вынести установку пакетов из package.json в отдельные шаги. Т.е. вместо добавления всех исходников и установки пакетов, в образ сначала добавляются только package.json. Это позволяет улучшить кеширование (т.к. исходный код меняется часто, а package.json - нет)

Лично для меня новыми были 2 техники: установка пакетов с копированием только package.json (не совсем новое, но давненько про это не читал и не использовал) и запуск кастомного скрипта чтобы зафорсить кеширование определенных слоев (автор удаляет лишние зависимости из package.json, но это также можно использовать и для удаления или изменения полей, например version)

https://www.specfy.io/blog/1-efficient-dockerfile-nodejs-in-7-steps

#development #nodejs #docker #recommended

Yes, you should test on production…

Статья объясняет, почему необходимо стремиться к тому, чтобы тестировать прямо на проде. Если коротко: это экономически выгодно

В целом, автор, конечно же, говорит о том, что существуют разные контексты. В одних мы не можем тестировать постоянно на проде (финансы, медицина и тд), в других же можем. Основной критерий для принятия решения о тестировании на проде - это ответ на вопрос "а что может случится?". Если вы делаете ПО для атомных реакторов, то тестировать на проде, очевидно, плохая идея. Если вы еще не запустились - то почему нет? Ведь для заведения тестовых стендов, регламентов, проверок нужно постоянно тратить время, а мы ничем не рискуем

Мысль в статье растекается достаточно широко, поэтому я отмечу основные поинты рассуждений

Мы можем определить "уверенность в поставке" как уверенность здравомыслящего разработчика когда он узнает, что его код скоро будет на проде. У SpaceX нужно тестировать ПО, а github может спокойно раскатить что угодно, в худшем случае напишут "мы полежим 10 минут и восстановимся" и они находятся на разных концах шкалы уверенности в поставке

Если взять 2 оси - уверенность в поставке и критичность, то мы получим 4 квадрата (критично + уверены, некритично + неуверены, критично + неуверены, некритично + уверены)

Идеальный квадрат - некритично и мы уверены. Это значит что мы можем безопасно и быстро разрабатывать. Самый плохой квадрат - некритично и нет уверенности. Это означает, что мы делаем долго неважные вещи. Критично и нет уверенности это как раз про медленную но безопасную разработку, а критично и уверенны в том что все ок - история про стартапы, где надо рисковать.

Увеличение проверок и регламентов, которые идут рука об руку с неуверенностью в поставке, ведут к ухудшению developer experience, что ведет к дорогой разработке. Поэтому это должно использоваться только в областях или фичах с большой критичностью

В остальных же случаях тестирование прямо на проде может оказаться экономически выгоднее (если мы умеем быстро откатываться, то фин потери от плохого релиза меньше, чем траты на тестирование, настройку и поддержку инфраструктуры и ожидания задач)

https://marcochiappetta.medium.com/yes-you-should-test-on-production-61f6dc61908b

#managment #devops