1. Сначала идентичность, потом деплой Надежный релиз должен отвечать на простой вопрос: какой именно набор исходников сейчас работает в среде? Для этого недостаточно имени ветки или тега latest. Кандидат связывается с точным Git SHA, а собранный образ получает собственную неизменяемую идентичность.
Такой подход убирает класс ошибок, когда staging проверял один код, а production случайно получил другой.
2. Один и тот же артефакт на staging и production Staging полезен только тогда, когда проверяет тот же кандидат, который планируется продвигать дальше. Идеальная цепочка выглядит так: 1. Синхронизировать exact SHA. 2. Собрать immutable candidate. 3. Развернуть его на staging. 4. Выполнить browser, API и runtime проверки. 5. Продвинуть тот же кандидат в production без повторной сборки «из текущего состояния».
Это превращает staging из демонстрационной среды в доказательство пригодности конкретного релиза.
3. Release gates и безопасный rollback Production promotion должен быть отдельным действием с явными условиями допуска. Перед ним проверяются состояние среды, результаты staging, возможность rollback и точная идентичность кандидата.
Rollback тоже должен ссылаться на известный предыдущий артефакт, а не пытаться «откатить код» вручную. Чем меньше импровизации в аварийный момент, тем быстрее и безопаснее восстановление.
4. Post-deploy evidence вместо доверия Зеленый статус команды deploy еще не доказывает, что пользователь получил нужную версию. После релиза нужны независимые проверки: - runtime сообщает ожидаемый revision; - публичные маршруты отвечают; - ключевые пользовательские сценарии проходят; - результат записан в долговечный журнал.
В итоге релиз становится воспроизводимой инженерной процедурой, а не последовательностью ручных действий.