Измерение эффективности CI/CD с помощью метрик DevOps

CI-сервер, или билд-сервер, координирует все этапы CI/CD-процесса: от отслеживания изменений в VCS до развертывания новых сборок.

CI-сервер упрощает процессы непрерывной интеграции и доставки/развертывания (CI/CD). Он отслеживает изменения в системе контроля версий (VCS), запускает автоматическую сборку, тестирование и развертывание, собирает результаты и запускает следующий этап пайплайна.

Хотя использование билд-сервера необязательно для CI/CD, многие команды предпочитают его иметь для координации процессов и создания отчетов о каждом этапе. В этом руководстве мы расскажем, как работает сервер непрерывной интеграции и как он помогает эффективно использовать все возможности CI/CD.

Преимущества сервера непрерывной интеграции

CI-сервер служит центром, координирующим все процессы в рамках CI/CD-пайплайна. Использование CI-сервера:

  • Гарантирует, что каждый коммит пройдет через CI/CD-пайплайн. Благодаря интеграции с VCS сервер непрерывной интеграции гарантирует, что для всех изменений кода будет выполнена автоматическая сборка, тестирование и развертывание без дополнительных усилий со стороны разработчиков.
  • Позволяет согласовать бизнес-логику. CI-сервер служит единым источником требований для всей вашей команды: от необхадимого уровня покрытия тестами до критериев успешного прохождения каждого этапа автоматического тестирования.
  • Интегрируется в ваш тулчейн. Помимо VCS и инструментов сборки, CI-сервер может подключаться к баг-трекерам и платформам для общения, автоматически отправляя обновления о процессе сборки, тестирования и развертывания.
  • Помогает вести журнал сборок. Архив артефактов сборки незаменим, когда нужно установить точку, в которой в кодовой базе появилась какая-нибудь особенно трудноуловимая ошибка.
  • Дает всем заинтересованным сторонам возможность отслеживать ход релиза. Поскольку CI-сервер является центральным первоисточником статусов сборки и развертывания, его можно использовать для широкого информирования о ходе работы.
  • Предоставляет журнал аудита изменений. Рабочие процессы и бизнес-логика со временим могут меняться. Используя CI-сервер вы сохраняете данные о том, как изменился CI/CD-пайплайн, на случай, если захотите вернуться к одной из предыдущих версий.

В то же время использование сервера непрерывной интеграция позволяет полнее использовать преимущества CI/CD, в том числе быструю обратную связь по изменениям кода, раннее выявление ошибок и более частые релизы.

Преимущества CI/CD-сервера

Как работает CI-сервер

Процесс может быть организован по-разному в зависимости от требований вашей команды и организации, но как правило сервер непрерывной интеграции выполняет следующее:

  1. Интегрируется с системой контроля версий и отслеживает коммиты в соответствующих ветках.
  2. Запускает последовательность задач сборки и тестирования при каждом коммите изменений. Они могут выполняться на других машинах, входящих в билд-ферму, или на самом CI-сервере.
  3. Обрабатывает результаты выполнения этих задач и на основе полученных данных определяет, нужно ли переходить к следующему этапу.
  4. Хранит артефакты сборки в центральном архиве.
  5. Выполняет развертывание новой версии в производственную среду.
  6. Предоставляет обратную связь по ходу всего процесса.
Как работает CI-сервер

Мониторинг системы контроля версий

Любой CI/CD-пайплайн начинается с интеграции с системой контроля версий.

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

Некоторые CI-серверы позволяет сделать еще один шаг: они требуют, чтобы разработчики протестировали изменения локально и лишь затем публиковали их в ветке непрерывной интеграции. Это все равно не гарантирует отсутствие ошибок на следующем этапе, но позволяет сократить число ошибок сборки и вызванных ими задержек. Кроме того, можно интегрировать CI-сервер с вашим инструментом для код-ревью, чтобы каждый коммит обязательно проходил код-ревью и отправлялся только в случае его успеха.

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

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

Каждый раз при обнаружении изменений запускается пайплайн. При этом сервер непрерывной интеграции координирует задачи сборки и тестирования. Обычно они выполняются на специальных машинах, или «билд-агентах». Агенты берут на себя работу по запуску сборок и выполнению тестов в соответствии с инструкциями, полученными от сервера непрерывной интеграции.

Можно также выполнять задания сборки и тестирования на самом CI-сервере. Однако это может привести к нехватке ресурсов и снижению производительности на активных кодовых базах.

При использовании сервера непрерывной интеграции для организации логики этапа вашего пайплайна есть возможность задать особые условия и правила. Например, вы можете:

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

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

Билд-сервер, интегрированный с облачной инфраструктурой, такой как AWS, позволяет воспользоваться преимуществами гибких, масштабируемых ресурсов для выполнения сборок и тестов. Если у вас повышенные требования к инфраструктуре, поддержка контейнерных билд-агентов и интеграция с Kubernetes позволит эффективно распорядиться ресурсами сборки, независимо от их расположения — в облаке или в локальной инфраструктуре.

Определение условий удачного и неудачного завершения сборки

Важнейшей составляющей вашей бизнес-логики является определение того, что считать неудачным завершением сборки на каждом этапе CI/CD-пайплайна.

CI-сервер должен давать возможность настроить разные условия неудачного завершения сборки. Затем он будет использовать их для определения состояния того или иного этапа и принимать решение, можно ли перейти к следующему этапу пайплайна.

Помимо очевидных неудачных завершений сборки (например, когда возвращается код ошибки или не выполняются тесты), можно задать и другие условия неудачных завершений на основе данных, собранных билд-сервером.

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

На основании этих данных можно сделать вывод о возможном снижении качества кода. Задав эти метрики в качества триггера для неудачного завершения сборки и ограничив число пользователей, которым разрешено игнорировать эти сбои, можно добиться нужного сценария выполнения сборки.

Хранение артефактов сборки

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

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

Кроме того, репозиторий артефактов успешных сборок полезен, если вам нужно вернуться к предыдущей версии ПО или когда вы пытаетесь выяснить, в какой момент появилась та или иная ошибка.

Развертывание сборок

Хотя название «сервер непрерывной интеграции» предполагает, что его использование ограничивается только непрерывной интеграцией, большинство CI-серверов также поддерживают непрерывную доставку и развертывание.

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

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

Обратная связь

Главная задача сервера непрерывной интеграции — обеспечить быструю обратную связь на каждом этапе сборки и тестирования. Если CI-сервер интегрирован с IDE или коммуникационной платформой, он может отправлять вам уведомления каждый раз, когда внесенные вами изменения приводят к неудаче при выполнении пайплайна, так что вам не надо постоянно отслеживать ситуацию.

Кроме того, билд-серверы могут:

  • предоставлять отчеты в реальном времени о текущих сборках и тестах, а также уведомлять о завершении этапов сборки;
  • интегрироваться с баг-трекерами, чтобы вы могли видеть, какие исправления содержит коммит, и быстро исследовать причины ошибок;
  • сводить статистику по частоте развертываний, времени до следующей ошибки и среднему времени устранения ошибок — это поможет вам оценить качество процесса разработки и улучшить его;
  • предоставлять информацию об использовании и производительности сервера непрерывной интеграции и билд-машин, которые можно использовать для оптимизации пайплайнов.
Что делают билд-серверы

Нужен ли вам свой CI-сервер

Свой сервер непрерывной интеграции может быть перспективным вариантом. Собственное решение всегда можно настроить под свои требования, не платя за лицензию.

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

Нужно помнить и о том, сколько сил потребуется на интеграцию CI-сервера в ваш тулчейн. Первоначальная конфигурация будет работать с определенной системой контроля версий, баг-трекером, инструментами сборки и тестовыми фреймворками, которые вы сейчас используете. А если вы решите перейти на новый продукт или технологию?

Собственный сервер непрерывной интеграции — инструмент, который можно гибко настроить под свои нужды, но его создание и обслуживание требует немалых и постоянных затрат.

Заключение

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

Чем поможет TeamCity

TeamCity — это CI-сервер, который поддерживает интеграцию с основными системами контроля версий, включая Git, Perforce, Mercurial и Subversion, а также различными хостинг-сервисами. Кроме того, вы получаете поддержку множества инструментов сборки и тестовых фреймворков, а также интеграцию с IDE, баг-трекерами, мессенджерами и диспетчерами контейнеров.

TeamCity Professional и Enterprise позволяют настроить сервер непрерывной интеграции как локально, так и в облаке, а если вы предпочитаете полностью управляемое решение, выбирайте TeamCity Cloud. Гибкая настройка триггеров позволяет запускать CI/CD-пайплайн по вашим требованиям: тестировать коммиты, работать с ветками функций или запускать сборки по расписанию. Логику пайплайна можно настроить через интерфейс и сохранить как код, чтобы обеспечить полный контроль версий CI/CD-пайплайна.