Что такое автоматизация сборки в DevOps?
Автоматическая сборка играет главную роль в автоматизации непрерывной интеграции (CI) и является важным фактором в реализации CI/CD-пайплайна. Это первый в целой серии автоматизированных шагов, которые помогают как можно раньше выявить возможные проблемы, вызванные свежими изменениями в коде.
Говоря в этом контексте о сборке, мы имеем в виду не просто процесс компиляции и связывания исходного кода для создания исполняемого файла.
Процесс автоматической сборки включает в себя ряд проверок, а также подбор всех элементов, необходимых для работы программы. Этап сборки необходим, даже если вы пишете код на интерпретируемом языке.
Файлы, созданные на этапе сборки (артефакты сборки), затем проходят следующие этапы CI/CD-пайплайна: тестирование и развертывание в тестовом окружении. После успешного прохождения всех этапов пайплайна сборка готова к развертыванию в производственную среду.
Зачем автоматизировать процессы сборки и развертывания?
Прежде чем перейти к тому, что предусматривает управление автоматизацией сборки, давайте разберемся, почему этот процесс вообще необходимо автоматизировать.
Если вы работаете в IDE, для запуска сборки обычно достаточно нажать сочетание клавиш. Зачем автоматизировать этот процесс?
Начнем с того, что локальная сборка удобна для быстрой проверки работоспособности кода или демонстрации работы начальству. Однако использовать локальную сборку в CI/CD-пайплайне — неудачное решение.
Если вы используете выделенный билд-сервер, это гарантирует чистую среду и позволяет быстро выявить все отсутствующие зависимости. В противном случае после развертывания продукта в тестовой среде возникнут ошибки и задержки.
Кроме того, без автоматической сборки, которая запускает все следующие этапы пайплайна, CI/CD работает гораздо менее надежно. Представьте себе, что вам нужно не забыть зайти в систему билд-сервера и запустить каждую сборку, включая все связанные с этим тесты, проконтролировать процесс и убедиться в отсутствии ошибок, а потом перенести итоговые файлы в репозиторий артефактов, чтобы их можно было развернуть в тестовой среде. На каждом этапе не исключены человеческие ошибки.
Очень соблазнительно отложить запуск сборки, пока не будут готовы еще несколько изменений, чтоб протестировать все сразу, однако это сводит на нет преимущества CI/CD.
В конечном итоге стратегическая задача CI/CD-пайплайна — быстро выявлять ошибки.
Чем раньше вы узнаете о проблеме, тем проще будет ее устранить и тем выше будет эффективность процесса автоматизации сборки. Автоматизировать этап сборки проще, чем вручную запускать все предусмотренные шаги, и намного быстрее, чем вручную перемещать файлы и выполнять тестирование.
Автоматизация сборки гарантирует, что все шаги будут выполнены в нужно порядке для каждого коммита или пакета коммитов, и вы быстро получите обратную связь, сэкономив время.
Как работает автоматизация сборки в CI/CD-пайплайне?
Если вы только знакомитесь с CI/CD, настройка автоматической сборки и ее запуска каждый раз, когда кто-то из членов команды делает коммит изменений, — одна из первых вещей, которые необходимо сделать (сразу после загрузки всех данных в систему контроля версий). Возможно, у вас уже есть билд-скрипт или файл определения, если он имеется в IDE или вы написали его самостоятельно.
В противном случае нужно выбрать подходящий инструмент автоматизации сборки для вашего рабочего языка и указать файлы, которые необходимо скомпилировать, связать и упаковать. После этого для координации различных шагов — от первоначального запуска до получения обратной связи и определения условий неудачного завершения сборки — можно использовать сервер непрерывной интеграции.
Запуск сборки
Автоматизированная непрерывная интеграция подразумевает, что каждый коммит в ветку master становится триггером сборки. В результате все изменения интегрируются и тестируются вскоре после того, как будут сделаны. Успешное завершение сборки служит триггером следующего этапа процесса.
Большинство инструментов для CI позволяют задать дополнительные триггеры сборки и настроить следующие этапы пайплайна.
Например, можно запускать некоторый набор шагов при коммите в любую ветку определенной директории или при помощи инструмента развертывания запланировать ночной запуск сборки, которая проходит дополнительные уровни тестирования и используется для обновления предпроизводственных сред. Кроме того, этап сборки можно запускать и вручную.
Выполнение сборки
Рекомендуется выполнять все шаги сборки на выделенном билд-сервере, а не на машине разработчика. Если сборка выполняется в чистой среде, это поможет сразу найти отсутствующие зависимости и избежать в дальнейшем проблем типа «а на моей машине все работает».
На этапе сборки происходит вызов выбранного инструмента (например, Maven, Ant или Gradle), который и выполняет задачи, определенные в билд-скрипте или файле определения.
Когда вы получите представление о том, сколько времени выполняется сборка, стоит при помощи инструмента развертывания настроить условие неудачного завершения для сборок, которые не будут завершены за определенный отрезок времени. Это позволит предотвратить блокировку ресурсов из-за слишком продолжительной сборки.
Выполнение тестов
Помимо подготовки кода к развертыванию, процесс управления автоматизацией сборки — идеальный момент для проведения ряда других проверок кода: например, юнит-тестирования, линтинга и статического анализа кода. Эти проверки стоит выполнять с помощью инструмента развертывания при каждой сборке, чтобы сразу же устранить обнаруженные проблемы. Это поможет повысить качество кода.
Указанные проверки выполняются до создания артефактов сборки, но обнаруженные ошибки не обязательно приводят к остановке пайплайна. Например, вы можете публиковать артефакт сборки и переходить к следующему этапу пайплайна, даже если обнаружены ошибки при проверке кода. Рекомендуем настроить пороговое значение качества кода: тогда «мелкие» проблемы не будут постепенно накапливаться.
Публикация артефактов сборки
Результатом автоматической сборки становятся артефакты сборки. Они могут включать в себя установщики, WAR-файлы, библиотеки и контейнеры. Публикуя эти файлы в репозиторий артефактов, вы получаете централизованное хранилище, откуда можно развернуть сборки в разные среды, в идеале с помощью инструментов развертывания.
Следующий этап CI/CD-пайплайна после завершения сборки обычно включает в себя автоматическое функциональное тестирование. Для этого сборку необходимо развернуть в одной или нескольких тестовых средах (иногда вместе с другими компонентами — например, с базой данных или другими микросервисами). После успешного завершения тестов ту же сборку можно использовать для обновления предпроизводственных сред и при необходимости развернуть в производственной среде.
Метрики и обратная связь
Инструмент непрерывной интеграции позволяет посмотреть результаты сборки, в том числе понять, успешно ли она завершилась, а также результаты юнит-тестирования и других проверок. Настроив уведомления о возможных сбоях, вы сможете быстро отреагировать на возникшие проблемы и восстановить рабочее состояние кода.
Кроме того, инструмент развертывания отсортирует данные из пайплайна, позволяя вам проанализировать тенденции. Анализ истории сборок и таких метрик, как продолжительность сборки, доля успешных сборок и покрытие кода, помогает выявить возможные сложности и улучшить процесс CI/CD.
Подводя итог
Автоматизация сборок — один из главных шагов при создании CI/CD-пайплайна в целом при управлении сборками. В этом отношении выбор подходящих инструментов развертывания является очень важным. Этап сборки обеспечивает первый цикл быстрой обратной связи и закладывает основу для следующих этапов пайплайна: от автоматического тестирования до непрерывной доставки и развертывания.