I would like to view this page in
CI-сервер, или билд-сервер, координирует все этапы CI/CD-процесса: от отслеживания изменений в VCS до развертывания новых сборок.
CI-сервер упрощает процессы непрерывной интеграции и доставки/развертывания (CI/CD). Он отслеживает изменения в системе контроля версий (VCS), запускает автоматическую сборку, тестирование и развертывание, собирает результаты и запускает следующий этап пайплайна.
Хотя использование билд-сервера необязательно для CI/CD, многие команды предпочитают его иметь для координации процессов и создания отчетов о каждом этапе. В этом руководстве мы расскажем, как работает сервер непрерывной интеграции и как он помогает эффективно использовать все возможности CI/CD.
CI-сервер служит центром, координирующим все процессы в рамках CI/CD-пайплайна. Использование CI-сервера:
В то же время использование сервера непрерывной интеграция позволяет полнее использовать преимущества CI/CD, в том числе быструю обратную связь по изменениям кода, раннее выявление ошибок и более частые релизы.
Процесс может быть организован по-разному в зависимости от требований вашей команды и организации, но как правило сервер непрерывной интеграции выполняет следующее:
Любой CI/CD-пайплайн начинается с интеграции с системой контроля версий.
Обычно сервер непрерывной интеграции настраивается на отслеживание коммитов в определенной ветке. При появлении изменений происходит запуск пайплайна. Таким образом, каждый раз, когда разработчик публикует изменения в коде, выполняется сборки и тестирование, чтобы гарантировать, что кодовая база работает должным образом.
Некоторые CI-серверы позволяет сделать еще один шаг: они требуют, чтобы разработчики протестировали изменения локально и лишь затем публиковали их в ветке непрерывной интеграции. Это все равно не гарантирует отсутствие ошибок на следующем этапе, но позволяет сократить число ошибок сборки и вызванных ими задержек. Кроме того, можно интегрировать CI-сервер с вашим инструментом для код-ревью, чтобы каждый коммит обязательно проходил код-ревью и отправлялся только в случае его успеха.
Благодаря реализации этих дополнительных уровней бизнес-логики в начале процесса, поддерживается чистота кодовой базы и обеспечивается ее готовность к выпуску, при этом минимизируются прерывания и задержки в пайплайне.
Каждый раз при обнаружении изменений запускается пайплайн. При этом сервер непрерывной интеграции координирует задачи сборки и тестирования. Обычно они выполняются на специальных машинах, или «билд-агентах». Агенты берут на себя работу по запуску сборок и выполнению тестов в соответствии с инструкциями, полученными от сервера непрерывной интеграции.
Можно также выполнять задания сборки и тестирования на самом CI-сервере. Однако это может привести к нехватке ресурсов и снижению производительности на активных кодовых базах.
При использовании сервера непрерывной интеграции для организации логики этапа вашего пайплайна есть возможность задать особые условия и правила. Например, вы можете:
Одновременный запуск определенных заданий с использованием разных билд-агентов может повысить эффективность вашего пайплайна. Это полезно, когда необходимо запустить тесты на разных операционных системах или когда вы работаете с огромной кодовой базой, а тесты исчисляются сотнями тысяч, в этом случае единственный рациональный выход — параллельное выполнение. Во втором случае использование композитной сборки позволит объединить результаты, чтобы можно было обрабатывать задания за один шаг сборки.
Билд-сервер, интегрированный с облачной инфраструктурой, такой как AWS, позволяет воспользоваться преимуществами гибких, масштабируемых ресурсов для выполнения сборок и тестов. Если у вас повышенные требования к инфраструктуре, поддержка контейнерных билд-агентов и интеграция с Kubernetes позволит эффективно распорядиться ресурсами сборки, независимо от их расположения — в облаке или в локальной инфраструктуре.
Важнейшей составляющей вашей бизнес-логики является определение того, что считать неудачным завершением сборки на каждом этапе CI/CD-пайплайна.
CI-сервер должен давать возможность настроить разные условия неудачного завершения сборки. Затем он будет использовать их для определения состояния того или иного этапа и принимать решение, можно ли перейти к следующему этапу пайплайна.
Помимо очевидных неудачных завершений сборки (например, когда возвращается код ошибки или не выполняются тесты), можно задать и другие условия неудачных завершений на основе данных, собранных билд-сервером.
Это может быть уменьшение покрытия кода тестами по сравнению с предыдущей сборкой (а значит, для очередных изменений кода не были добавлены тесты) или увеличение количества проигнорированных тестов по сравнению с последней успешной сборкой.
На основании этих данных можно сделать вывод о возможном снижении качества кода. Задав эти метрики в качества триггера для неудачного завершения сборки и ограничив число пользователей, которым разрешено игнорировать эти сбои, можно добиться нужного сценария выполнения сборки.
Если изменение успешно прошло все проверки, сервер непрерывной интеграции сохраняет артефакты процесса сборки. Сюда могут входить исполняемые файлы, установщики, образы контейнеров и любые другие ресурсы, необходимые для развертывания ПО.
В дальнейшем эти же артефакты можно развернуть в препродакшн-окружении для дальнейшего тестирования перед развертыванием в производственную среду. Благодаря этому на всех этапах тестирование выполняется на одних и тех же артефактах, и это существенно надежнее, чем перед каждым развертыванием заново собирать их из исходного кода. В частности, не будет проблем из-за отсутствующих зависимостей и других несоответствий.
Кроме того, репозиторий артефактов успешных сборок полезен, если вам нужно вернуться к предыдущей версии ПО или когда вы пытаетесь выяснить, в какой момент появилась та или иная ошибка.
Хотя название «сервер непрерывной интеграции» предполагает, что его использование ограничивается только непрерывной интеграцией, большинство CI-серверов также поддерживают непрерывную доставку и развертывание.
После формирования артефактов сборки и выполнения исходного набора тестов во время этапа непрерывной интеграции следующим шагом является развертывание этих артефактов в тестовых средах для дальнейшего тестирования. После этого следует проверка рабочей версии всеми заинтересованными сторонами на тестовом окружении. Если на этом этапе нареканий нет, то за ним обычно следует релиз.
CI-сервер можно использовать для хранения параметров каждого окружения в пайплайне и управления ими. Это позволяет указать, должны ли ваши скрипты развертывания автоматически срабатывать в зависимости от результатов, полученных на предыдущем этапе.
Главная задача сервера непрерывной интеграции — обеспечить быструю обратную связь на каждом этапе сборки и тестирования. Если CI-сервер интегрирован с IDE или коммуникационной платформой, он может отправлять вам уведомления каждый раз, когда внесенные вами изменения приводят к неудаче при выполнении пайплайна, так что вам не надо постоянно отслеживать ситуацию.
Кроме того, билд-серверы могут:
Свой сервер непрерывной интеграции может быть перспективным вариантом. Собственное решение всегда можно настроить под свои требования, не платя за лицензию.
Однако создание собственного инструмента — это лишь первый шаг. Когда сервер будет запущен, нужно будет вкладывать силы и средства в его обслуживание и поддержание на современном уровне, в том числе устранять возникающие ошибки и добавлять новые функции по мере роста требований.
Нужно помнить и о том, сколько сил потребуется на интеграцию CI-сервера в ваш тулчейн. Первоначальная конфигурация будет работать с определенной системой контроля версий, баг-трекером, инструментами сборки и тестовыми фреймворками, которые вы сейчас используете. А если вы решите перейти на новый продукт или технологию?
Собственный сервер непрерывной интеграции — инструмент, который можно гибко настроить под свои нужды, но его создание и обслуживание требует немалых и постоянных затрат.
Сервер непрерывной интеграции играет важную роль в работе вашего CI/CD-пайплайна, координируя и запуская различные стадии проекта, а также собирая и передавая данные по каждому этапу. В нашем Руководстве по инструментам CI/CD есть рекомендации, как выбрать подходящий сервер непрерывной интеграции.
TeamCity — это CI-сервер, который поддерживает интеграцию с основными системами контроля версий, включая Git, Perforce, Mercurial и Subversion, а также различными хостинг-сервисами. Кроме того, вы получаете поддержку множества инструментов сборки и тестовых фреймворков, а также интеграцию с IDE, баг-трекерами, мессенджерами и диспетчерами контейнеров.
TeamCity Professional и Enterprise позволяют настроить сервер непрерывной интеграции как локально, так и в облаке, а если вы предпочитаете полностью управляемое решение, выбирайте TeamCity Cloud. Гибкая настройка триггеров позволяет запускать CI/CD-пайплайн по вашим требованиям: тестировать коммиты, работать с ветками функций или запускать сборки по расписанию. Логику пайплайна можно настроить через интерфейс и сохранить как код, чтобы обеспечить полный контроль версий CI/CD-пайплайна.
Непрерывная доставка (CD — Continuous delivery) предполагает автоматизацию ручных шагов, необходимых для сборки и выпуска ПО.
Стратегии работы с ветками — одна из тем, по которым то и дело разгораются жаркие споры как в интернете, так и в реальной жизни точно так же, как о предпочтительном использовании пробелов или табуляции.
Что же все-таки такое пайплайн непрерывной интеграции и доставки? И как его настроить? Об этом — в нашей статье.