Как поступают с артефактами сборки при таком подходе к деплою?

Управление артефактами сборки при деплое

Артефакты сборки — это результат компиляции или сборки исходного кода, включая исполняемые файлы, библиотеки, Docker-образы или пакеты. При подходе к деплою, основанном на CI/CD, артефакты не хранятся локально на сервере сборки, а передаются в централизованное хранилище. Это гарантирует, что каждый этап развертывания использует одну и ту же версию артефакта, исключая расхождения.

Основные принципы

• Версионирование: Каждый артефакт получает уникальный идентификатор (например, номер сборки или тег Git).
• Хранение: Используются специализированные системы: Nexus, Artifactory, Docker Registry или облачные сервисы (AWS S3, Google Cloud Storage).
• Воспроизводимость: Артефакты собираются один раз и используются на всех этапах (тестирование, стейджинг, продакшн).

Пример настройки в CI/CD (GitLab CI)

stages:
  - build
  - deploy

build_job:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy_job:
  stage: deploy
  script:
    - scp -r dist/ user@server:/var/www/app
  dependencies:
    - build_job

В этом примере артефакты (папка dist) сохраняются после сборки и передаются в задачу деплоя. Если используется Docker, образ пушится в реестр:

docker build -t myapp:$CI_COMMIT_SHORT_SHA .
docker push myapp:$CI_COMMIT_SHORT_SHA

Вывод

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