Как-то делал для команды CI/CD workflow. Стандартная история: взял их образец, подрихтовал - правильные Docker-слои, минимализм, билд заранее, а не при старте контейнера.
Сделал. Задеплоилось и в dev, и в prod. Работает. Красота.
Через 2 дня звонок: “В проде всё сломалось.”
Полез разбираться. Нашёл быстро: в package.json стояла зависимость с тегом :dev. Для продакшена.
То есть кто-то поставил dev-версию сторонней библиотеки в прод. В этой версии что-то изменилось - либо баг, либо breaking changes. Прод лежит.
Урок: я сделал pipeline правильным для себя. Но забыл про команду.
Я построил всё как надо. Со своей стороны. Но забыл про главное: люди не идеальны. Кто-то поставит :dev в прод. Кто-то забудет зафиксировать версию. Кто-то вообще не знает, что так нельзя.
Знаете, как “нельзя коммитить пароли в git”? Точно так же: нельзя использовать dev-версии библиотек в проде. Но правило знать мало - нужна система, которая не даст нарушить его случайно.
Раньше я строил “правильные” CI/CD со своей стороны. Pipeline работает? ✅ Моя работа закончена.
Теперь - надёжные. С автоматическими проверками не только моего кода, но и типичных косяков команды:
- Линтеры для версий зависимостей
- Проверки конфигов перед деплоем
- Автотесты на “что не должно попасть в прод”
Не потому что не доверяю людям.
А потому что хорошая система не полагается на то, что все всегда помнят правила.
Моя работа - делать так, чтобы люди физически не могли выстрелить себе в ногу. Не через ограничения “обратитесь к администратору”, а через автоматические проверки, которые ловят ошибки до прода.
Linux даёт мне rm -rf / - и это правильно, мне нужна эта свобода.
Но команде разработки я даю систему, где :dev в prod просто не пройдёт первичную проверку.
Делаю аудит IT-инфраструктуры.
https://itaudit.yushkov.org/ru/index.html
Нахожу не только “что сломано”, но и “что сломается при следующей случайной ошибке человека”.
Потому что prod не должен падать из-за :dev в package.json.