В CI/CD тестируется один артефакт, а перед production собирается другой. Какой принцип публикации устраняет риск расхождения между проверенной и выпущенной версией?
Нужно применять принцип собери один раз — продвигай тот же артефакт. Артефакт, прошедший проверки, должен неизменно перемещаться между окружениями, а production не должен пересобирать приложение заново.
Так устраняется риск, что проверенная версия и фактически выпущенная версия различаются из-за времени сборки, зависимостей, параметров окружения или состояния исходного кода.
Ранние процессы часто собирали приложение отдельно для тестового, предпродукционного и production-окружения. Такой подход казался удобным, но постепенно выявил проблему: успешное тестирование одной сборки не гарантирует свойства другой.
Практика immutable artifacts появилась как ответ на этот разрыв. Она переносит доверие с повторяемости сборки на конкретный идентифицируемый результат сборки, который можно проверять, хранить и продвигать без изменения.
Если production-версия собирается заново, между двумя сборками могут измениться зависимости, базовый образ, инструменты сборки, переменные или исходный код. Даже при одинаковом номере версии результат может оказаться другим.
Последствие — тесты дают ложную уверенность: они подтверждают качество артефакта A, а пользователи получают артефакт B. Отладка усложняется, потому что команда не может однозначно связать инцидент с тем, что именно проходило проверки.
Сначала pipeline один раз собирает артефакт и присваивает ему неизменяемый идентификатор: например, хеш содержимого или уникальный номер сборки. Затем этот же объект сохраняется в реестре и последовательно проходит проверки, согласования и развёртывания.
Окружения должны различаться конфигурацией, секретами и внешними ресурсами, но не содержимым приложения. Перед развёртыванием нужно проверять, что выбран именно идентификатор артефакта, прошедшего обязательные quality gate.
Важно отделять артефакт от конфигурации окружения. Нельзя встраивать production-настройки повторной сборкой; их следует передавать на этапе запуска или развёртывания. При этом сама конфигурация тоже должна быть версионируемой и контролируемой.
Подход не устраняет все риски. Один и тот же артефакт может вести себя по-разному из-за несовместимой схемы базы данных, сетевых зависимостей или различий окружений. Поэтому нужны проверки совместимости, управление миграциями и контроль инфраструктуры.
Компромисс состоит в том, что команде требуется реестр артефактов, трассировка, политика хранения и дисциплина неизменяемости. Это повышает сложность процесса, но снижает стоимость расследований и делает результат релиза воспроизводимым.
Команда тестировала контейнерный образ в staging, а production pipeline перед выпуском заново выполнял сборку из той же ветки. После релиза обнаружилась ошибка, хотя staging был зелёным: за несколько минут обновилась транзитивная зависимость.
Рассматривались три варианта. Можно было чаще фиксировать версии зависимостей, что уменьшало вероятность расхождения, но не устраняло повторную сборку. Можно было добавить ещё один production-подобный прогон, что повышало уверенность, но увеличивало время поставки и всё равно не гарантировало идентичность.
Выбрали публикацию одного подписанного образа с уникальным идентификатором и его продвижение из staging в production без пересборки. Конфигурацию окружения вынесли отдельно, а pipeline связал результат тестов с конкретным образом.
После этого команда могла точно установить, какой образ был протестирован и выпущен. Риск расхождения сборок исчез, а расследование проблем стало опираться на воспроизводимый артефакт, а не на предположение о совпадении исходных условий.
Нет. Номер версии — только метка, которую можно присвоить разным содержимым. Надёжнее использовать неизменяемый идентификатор содержимого, например хеш, и хранить связь между ним, исходным коммитом, параметрами сборки и результатами проверок.
Да, если не изменяется сам артефакт и изменение конфигурации контролируется отдельно. Разные адреса сервисов, лимиты и секреты — нормальная часть окружения. Опасность возникает, когда конфигурация встраивается в приложение повторной сборкой или меняется вручную без аудита.
Нет. Оно гарантирует соответствие выпущенного содержимого протестированному, но не доказывает корректность окружения и сценариев эксплуатации. Дополнительно нужны проверки совместимости, миграций, инфраструктуры, мониторинг после выпуска и возможность быстрого отката к ранее проверенному артефакту.