Почему никогда не следует пересобирать артефакт после успешного тестирования

Представьте: ваша команда только что потратила три часа на прогон тестов сборки в стейджинге. Всё зелёное. Релиз-менеджер говорит: «Отлично, давайте пересоберём для продакшена». Кто-то запускает свежую компиляцию, пакует и деплоит. Через час продакшен начинает выдавать ошибки, которых никогда не было в стейджинге. Код тот же, но артефакт другой. Вы только что потеряли единственную гарантию, которая имела значение: то, что вы тестировали, — это не то, что работает.

Этот сценарий разыгрывается чаще, чем большинство команд готовы признать. Решение — не в лучшем инструменте сборки. Это дисциплина, которая начинается в тот момент, когда запускается ваш пайплайн.

Собрал один раз — используй везде

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

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

flowchart TD A[Коммит исходного кода] --> B[Сборка артефакта] B --> C[Вычисление контрольной суммы] C --> D[Загрузка в реестр] D --> E[Деплой в Dev] E --> F[Запуск тестов в Dev] F --> G{Тесты пройдены?} G -- Да --> H[Промоушн в реестре] G -- Нет --> I[Исправление кода и пересборка] H --> J[Деплой в Staging] J --> K[Запуск тестов в Staging] K --> L{Тесты пройдены?} L -- Да --> M[Промоушн в реестре] L -- Нет --> I M --> N[Проверка контрольной суммы] N --> O[Деплой в Production] O --> P[Продакшен работает] style B fill:#4CAF50,color:#fff style H fill:#FF9800,color:#fff style M fill:#FF9800,color:#fff style N fill:#2196F3,color:#fff

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

Тот же артефакт, который прошёл все проверки в стейджинге, должен быть тем же артефактом, который работает в продакшене. Если вы не можете этого гарантировать, вы не можете доверять своему тестированию.

Дайте каждому артефакту отслеживаемую идентичность

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

Автоматизируйте это. Никогда не позволяйте человеку назначать номер версии. Ваш пайплайн должен генерировать ID сборки, который объединяет:

  • Метку времени начала сборки
  • Порядковый номер сборки
  • Хеш Git-коммита

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

Помещайте артефакты в реестр, а не на сервер

Когда сборка завершается, артефакт должен немедленно покинуть CI-сервер. Он не должен лежать в рабочей области, на ноутбуке разработчика или в общей сетевой папке. Он отправляется прямиком в центральный реестр артефактов.

Реестр становится единым источником истины. Любая команда, любой пайплайн, любое окружение точно знают, где найти нужный артефакт. Без реестра вы будете изо всех сил пытаться ответить на простые вопросы вроде «Какая версия артефакта сейчас работает в продакшене?» или «Могу ли я воспроизвести точную сборку с прошломесячного релиза?»

Реестр также даёт вам контроль. Вы можете устанавливать права доступа, применять политики хранения и отслеживать, кто и что запрашивал. Эти возможности становятся критически важными по мере роста команды и появления множества пайплайнов, потребляющих артефакты.

Продвигайте, а не пересобирайте

Как только артефакт прошёл все тесты в стейджинге, пайплайн не должен пересобирать его для продакшена. Вместо этого он продвигает существующий артефакт. Промоушн означает изменение метаданных: обновление метки, перемещение артефакта в другую папку или пометку его как «готов к продакшену» в реестре.

Сам файл остаётся идентичным. Те же байты, которые прошли через все тесты, будут теми же байтами, которые будут работать в продакшене. Это основа воспроизводимых деплоев.

Но как узнать, что артефакт не был повреждён или изменён между тестированием и промоушном? Вот тут и нужна верификация.

Проверяйте, прежде чем доверять

Перед перемещением артефакта в продакшен ваш пайплайн должен проверить его целостность. Самый распространённый метод — проверка контрольной суммы.

Когда сборка завершается, пайплайн вычисляет контрольную сумму артефакта, обычно с помощью SHA256. Эта контрольная сумма сохраняется вместе с метаданными артефакта. Перед промоушном пайплайн пересчитывает контрольную сумму и сравнивает её с сохранённым значением. Если они не совпадают, что-то пошло не так. Файл мог быть повреждён при хранении, или кто-то мог изменить артефакт без разрешения.

Для более строгих гарантий используйте подпись. Пайплайн подписывает артефакт закрытым ключом команды. Во время промоушна реестр проверяет подпись. Подпись делает больше, чем просто проверка целостности. Она доказывает, что артефакт был собран именно вашим официальным пайплайном, а не кем-то ещё, кто получил доступ к вашему реестру. Это важно, когда несколько команд используют один реестр или когда артефакты загружаются из внешних источников.

Страховочная сеть

Эти четыре дисциплины работают вместе как страховочная сеть:

  • Сборка один раз обеспечивает согласованность между окружениями.
  • Автоматическое версионирование обеспечивает отслеживаемость до исходного кода.
  • Центральный реестр обеспечивает доступность для всех потребителей.
  • Промоушн без пересборки обеспечивает воспроизводимость.
  • Верификация обеспечивает доверие к целостности артефакта.

Если какая-то из этих дисциплин слаба, в вашем пайплайне есть дыра. У вас может быть красивая CI/CD-система на бумаге, но на практике вы находитесь в одной пересборке от инцидента в продакшене, который ваше тестирование никогда не поймало.

Быстрый чек-лист для вашего пайплайна

Если вы настраиваете или проверяете управление артефактами, пройдитесь по этому списку:

  • Собирает ли пайплайн каждый артефакт ровно один раз на коммит?
  • Есть ли у каждого артефакта автоматический, отслеживаемый идентификатор версии?
  • Загружаются ли артефакты в центральный реестр сразу после сборки?
  • Продвигает ли пайплайн артефакты, изменяя метаданные, а не пересобирая?
  • Выполняется ли проверка контрольной суммы или подписи перед промоушном в продакшен?

Если на любой из этих вопросов вы ответили «нет», у вас есть пробел, который стоит закрыть до следующего релиза.

Что это значит для вашей команды

Когда ваша команда последовательно следует этим дисциплинам, пайплайн становится предсказуемым. Вы перестаёте гадать, работает ли в продакшене тот же код, что прошёл тестирование. Вы перестаёте искать различия между сборками. Вы начинаете доверять своему процессу деплоя.

И как только это доверие установлено, вы можете сосредоточиться на следующем уровне: как артефакты перемещаются между окружениями, у кого есть полномочия на промоушн и как политики применяются автоматически. Но всё это не имеет значения, если вы не можете доверять самому артефакту. Собирайте один раз. Продвигайте, а не пересобирайте. Проверяйте перед деплоем. Всё остальное строится на этом фундаменте.