Артефакт сборки

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

Главное

Артефакт — это результат работы билд-системы (Jenkins, GitHub Actions), а не ручной процесс разработчика.
Объект обладает свойством неизменяемости: его нельзя редактировать, можно только заменять новой версией.
Хранится в специализированных репозиториях (Nexus, Artifactory) с привязкой к хешу коммита Git.
Гарантирует идентичность окружений: то, что прошло тесты, будет запущено на продакшене.

Как работает Артефакт сборки

Процесс создания начинается с триггера в системе контроля версий, например, при пуше в ветку main. CI/CD-Сервер клонирует Репозиторий и запускает Скрипт сборки. На этом этапе происходит установка зависимостей, линтинг кода и выполнение юнит-тестов. Если все проверки пройдены успешно, система упаковывает итоговые файлы в архив или образ. Затем создается уникальный идентификатор версии, часто включающий номер коммита и метку времени. Полученный пакет загружается в централизованное хранилище артефактов, откуда он может быть извлечен на следующих этапах пайплайна для деплоя или тестирования.

Зачем нужен Артефакт сборки

Основная цель использования заключается в обеспечении воспроизводимости и безопасности релизов. Без единого артефакта команда рискует столкнуться с проблемой «работает на моей машине», когда локальная Среда разработчика отличается от боевой. Объект сборки выступает как точка аудита: каждая версия жестко привязана к конкретному состоянию исходного кода. Это позволяет мгновенно откатиться к предыдущей стабильной версии при обнаружении критической ошибки. Кроме того, использование промежуточных артефактов ускоряет работу пайплайна, исключая необходимость повторной компиляции кода на каждом шаге.

Какие бывают виды артефакта сборки

Формат объекта зависит от целевой платформы и используемого стека технологий. В экосистеме Java популярны JAR и WAR-файлы, содержащие скомпилированный Байт-код и ресурсы. Для микросервисов стандартом де-факто стали Docker-образы, упакованные в слои. Фронтенд-приложения обычно генерируют статические HTML, CSS и JS-файлы, которые затем публикуются на CDN. Также существуют промежуточные артефакты: отчеты о покрытии кода, логи тестов или профили производительности, которые не разворачиваются, но важны для анализа качества продукта.

Где используется Артефакт сборки

Ключевая область применения — системы непрерывной доставки (CI/CD). Здесь объект передается между джобами: от стадии тестирования до стадии развертывания в облачные провайдеры (AWS, Azure, GCP). В контейнерных оркестраторах Kubernetes артефакт (образ) загружается в реестр и скачивается подами для запуска. В мобильной разработке APK и IPA-файлы используются для распространения приложений через магазины или внутренние системы дистрибуции. Инфраструктура как код (Terraform) также может использовать артефакты конфигураций для применения изменений в реальном мире.

Пример: установка и чтение артефакта сборки

Рассмотрим типичный сценарий в GitHub Actions, где результат сборки сохраняется для следующего шага. Ниже показан фрагмент YAML-конфигурации, демонстрирующий Сохранение статических файлов фронтенда.

yaml

name: Build and Deploy
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v3
        with:
          name: frontend-build
          path: dist/

В данном примере команда upload-artifact упаковывает папку dist в архив. Следующий шаг пайплайна может загрузить этот файл командой download-artifact, чтобы развернуть его на сервере без повторной сборки проекта.

Часто задаваемые вопросы артефакта сборки

Часто задаваемые вопросы

Можно ли изменять существующий артефакт?

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

Чем артефакт отличается от образа контейнера?

Docker-образ — это частный случай артефакта, упакованный по специфическому формату OCI. Обычный артефакт может быть просто ZIP-архивом или бинарным файлом, который не требует контейнеризации для запуска.

Сколько хранятся артефакты в CI/CD?

Это зависит от политики хранения. В некоторых системах они удаляются автоматически после определенного срока или количества версий. В корпоративных репозиториях (Artifactory) их могут хранить годами для соответствия регуляторным требованиям.

Что делать, если сборка упала?

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

Итоги

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

Он гарантирует, что Приложение собирается один раз и проходит все проверки до попадания в продакшен.
Неизменяемость объекта защищает от несанкционированных изменений и ошибок конфигурации.
Централизованное хранение позволяет командам работать параллельно над разными фичами.
Поддержка различных форматов делает его универсальным инструментом для любых технологических стеков.
Интеграция с системами мониторинга позволяет отслеживать Статус каждой выпущенной версии.