Где живут ваши сборки: почему каждому артефакту нужен дом

Представьте: ваш CI-пайплайн только что завершился успешно. Разработчик спрашивает: «Какую сборку деплоить на стейджинг?». Кто-то отвечает: «Кажется, ту, что со вчерашнего прогона». Другой добавляет: «Нет, я пересобрал локально сегодня утром. Используйте мою».

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

Решение простое по сути, но критически важное на практике: вам нужно единое централизованное место, где хранится результат каждой сборки. В терминах DevOps это место называется registry (реестр) или repository manager (менеджер репозиториев).

Артефакты бывают разными

Начнем с привычного типа артефактов: JAR-файл, ZIP-архив, скомпилированный бинарник или NuGet-пакет. Это однофайловые артефакты. Инструменты вроде Nexus, Artifactory или встроенные пакетные реестры вашей языковой экосистемы (npm registry, Maven Central, PyPI) отлично с ними справляются. Они хранят файл, отслеживают версии и позволяют пайплайнам или разработчикам забирать именно ту зависимость, которая нужна.

Теперь рассмотрим контейнерные образы. Контейнерный образ — это не один файл. Он состоит из нескольких слоев, наложенных друг на друга. Вы не можете хранить контейнерный образ в обычном репозитории артефактов. Для него нужен контейнерный registry: Docker Hub, Amazon ECR, Google Container Registry или Harbor. Контейнерные реестры понимают структуру слоев. Когда вы загружаете образ, registry отправляет только те слои, которых еще нет на целевой машине. Это ускоряет деплой и экономит трафик.

Контейнерные образы стали самым распространенным типом артефактов в современных CI/CD-пайплайнах. Но принцип остается тем же независимо от формата: registry — это единый источник истины для каждого артефакта, прошедшего сборку и тесты.

Registry — точка передачи между CI и CD

Вот самая важная функция registry в пайплайне: он обозначает границу между непрерывной интеграцией (CI) и непрерывной доставкой (CD).

Следующая диаграмма сравнивает правильный поток с «сломанным» потоком, который возникает при отсутствии registry.

flowchart TD subgraph Correct[С Registry] A1[CI Pipeline] -->|отправка артефакта с версией| B1[Registry] B1 -->|загрузка точного артефакта| C1[CD Pipeline] C1 --> D1[Staging] C1 --> E1[Production] end subgraph Broken[Без Registry] A2[CI Workspace] -->|ручное копирование| B2[Laptop] A2 -->|ручное копирование| C2[Shared Drive] B2 --> D2[Staging] C2 --> E2[Production] D2 -.->|несовпадение версий| E2 end Correct -.->|сравнение| Broken

Посмотрите на поток. Работа CI заканчивается в тот момент, когда артефакт попадает в registry с четким тегом версии. Сборка завершена. Тесты пройдены. Артефакт сохранен. Ответственность CI на этом прекращается.

CD начинается с registry. CD не пересобирает артефакт. Он загружает тот же самый артефакт, который сохранил CI, и разворачивает его в целевой среде. Никакой перекомпиляции. Никаких других зависимостей. Никакого «кажется, это та же сборка».

Это разделение не только техническое. Это вопрос ответственности. CI отвечает за корректность сборки. CD отвечает за корректность деплоя. Если что-то ломается в продакшне, вы отслеживаете проблему до конкретного артефакта в registry. Вы знаете его версию, хеш коммита, временную метку сборки. Никаких догадок.

Продвижение без модификации

Хороший registry также поддерживает продвижение (promotion) артефактов. Продвижение — это процесс пометки конкретного артефакта как готового для следующей среды. Вы не изменяете сам артефакт. Вы добавляете метаданные.

Например, ваш CI создает артефакт с тегом 1.2.3-build.45. Этот артефакт находится в registry. Когда он проходит тесты на стейджинге, вы добавляете тег: staging. Когда он проходит валидацию в продакшне, вы добавляете еще один тег: production. Базовый артефакт идентичен. Меняется только его статус.

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

Что происходит без registry

Команды, которые пропускают настройку правильного registry, снова и снова сталкиваются с одними и теми же проблемами:

  • Разработчики спрашивают друг друга, какую сборку деплоить.
  • Стейджинг работает на другой версии, чем продакшн.
  • Откаты превращаются в гадание, потому что никто не знает, что на самом деле было запущено до этого.
  • Сканирование безопасности выполняется для одних сборок, но не для других, так как нет централизованного инвентаря.
  • Аудиты соответствия требованиям превращаются в ручные цепочки писем с попытками восстановить, что было развернуто полгода назад.

Registry устраняет все эти проблемы. Это не роскошь. Это фундамент, на котором строятся дисциплинированные пайплайны.

Практический чек-лист для настройки registry

Если вы настраиваете registry впервые или пересматриваете текущую конфигурацию, вот краткий чек-лист:

  • Выберите правильный тип: контейнерный registry для образов, репозиторий артефактов для бинарников и пакетов. Некоторые инструменты, такие как Harbor или Artifactory, поддерживают оба типа.
  • Обеспечьте неизменяемость (immutability): как только артефакт сохранен с тегом версии, не позволяйте его перезаписывать. Новая сборка получает новую версию.
  • Настройте политики хранения: не каждая сборка должна жить вечно. Храните последние N сборок или сборки за последние M дней. Остальное архивируйте или удаляйте.
  • Контролируйте доступ: пайплайны должны иметь доступ на запись. Разработчики и CD-пайплайны — на чтение. Используйте IAM-роли или токены, а не общие пароли.
  • Явно помечайте продвижения: используйте метаданные или теги, чтобы отмечать, какие артефакты находятся на стейджинге, в продакшне или откачены. Автоматизируйте это в вашем CD-пайплайне.

Конкретный вывод

Registry — это не просто хранилище. Это контракт между процессом сборки и процессом деплоя. Он гарантирует, что то, что было собрано, будет именно тем, что развернуто. Он дает вашей команде единое место для поиска, когда что-то идет не так. Он делает продвижение отслеживаемым, а откаты — надежными.

Настройте registry до вашего следующего деплоя. Ваше будущее «я», отлаживающее инцидент в полночь, скажет вам спасибо.