Есть вещи, которые проще показать на чужом примере. Особенно когда этот пример — из производства, где косяки стоят дорого, а сроки срываются тихо.

Ошибка 1: CI/CD без тестов

Поставили Jenkins, написали pipeline, деплоим каждый час. Звучит красиво. Но в pipeline нет ни одного теста. Система доставляет баги в продакшен быстрее, чем кто-то успевает их заметить. Автоматизация без надёжности — это ускоренное разрушение.

Ошибка 2: ветка master как единственная защита

Все работают в master. PR нет. Ревью нет. Кто угодно может запушить что угодно. Через месяц в репозитории три стиля кодинга, два подхода к архитектуре и ноль понимания, кто что сломал.

Ошибка 3: нет мониторинга после деплоя

Деплой прошёл. Показывает OK. А что дальше? Метрики не собираются, алертов нет. Клиент звонит через два часа, а ты ещё не знаешь, что всё сломалось.

Ошибка 4: секреты в коде

API-ключи, пароли, токены — всё в .env или прямо в коде. Приходит новый разработчик, ему дают репозиторий, и вместе с кодом он получает доступ ко всему. Это не паранойя — это инструкция по безопасности.

Ошибка 5:deploy как событие, а не как процесс

Деплой делают раз в неделю, по пятницам, в пять вечера, все молятся. А надо — часто, маленькими шагами, с откатом. Когда деплой перестаёт быть событием, он перестаёт быть проблемой.

Что делать вместо этого

Простой чек-лист: тесты перед merge, мониторинг после каждого деплоя, secrets в Vault, деплой минимум раз в день. Не идеально, но уже лучше, чем «работает — не трогай».