Непрерывная интеграция (CI) — это практика DevOps, которая позволяет избежать проблем, возникающих в результате интеграции изменений на заключительных стадиях реализации проекта. Никто не хочет получить кучу конфликтов слияния и ошибок сборки, за которыми следуют многочисленные баги и горькое осознание того, что ваше ПО на самом деле не работает так, как нужно пользователю.
Непрерывная интеграция позволяет вам выполнять отправку, сборку и тестирование нового кода по мере его написания. Частая интеграция по ходу процесса разработки дает возможность минимизировать конфликты, проверять, как взаимодействуют изменения различных участников проекта, и исправлять ошибки, прежде чем они глубоко проникнут в кодовую базу и затронут работу других функций.
CI forms the first half of a continuous integration and delivery/deployment (CI/CD) pipeline – the ongoing process of committing, building, testing, staging and releasing each change, which delivers feedback at every stage and enables you to constantly iterate and improve.
Реализация CI/CD требует особого подхода к культуре труда для налаживания взаимодействия между различными командами и внедрения новых рабочих процессов. Помимо этого, необходимы инструменты для автоматизации различных этапов и обеспечения эффективной работы пайплайна.
Ключевую роль в этом играет сервер непрерывной интеграции (или билд-сервер). Это связующее звено, которое на основе вашей бизнес-логики объединяет все этапы пайплайна и координирует выполнение автоматизированных заданий, а также собирает данные и дает обратную связь. В этой статье мы более подробно рассмотрим, что делает сервер непрерывной интеграции и как он может помочь воспользоваться всеми преимуществами CI/CD.
At the start of any CI/CD pipeline is an integration with your version or source control system.
В рамках базовой реализации CI/CD-сервер настраивается на отслеживание коммитов, которые попадают в ветку master. В случае наличия изменения происходит запуск пайплайна.
И хотя при этом каждый коммит проверяется и тестируется, остается высокая вероятность, что кто-то отправит код, который сломает сборку, весь процесс прервется и другие изменения не будут проверяться, до тех пор пока проблемный код не будет удален или исправлен.
Настройка сервера непрерывной интеграции для выполнения сборки и тестирования изменений перед их отправкой помогает предотвратить такого рода проблемы и обеспечивает дополнительный цикл обратной связи для каждого разработчика.
Важно отметить, что билд-сервер не только управляет выполнением сборки и тестов на удаленной машине и передает их результаты разработчику, но и делает это условием для отправки изменений в основную или функциональную ветку.
Кроме того, вы можете рассмотреть возможность интеграции сервера непрерывной интеграции с вашим инструментом для код-ревью, чтобы перед отправкой каждый коммит обязательно проходил код-ревью и отправлялся только в случае успешного выполнения сборки и тестирования.
Благодаря реализации этих дополнительных уровней бизнес-логики в начале процесса, поддерживается чистота кодовой базы и обеспечивается ее готовность к выпуску, при этом минимизируются прерывания и задержки в пайплайне.
Когда дело доходит до запуска сборки и тестирования в рамках CI/CD-пайплайна, ваш CI-сервер становится центральным звеном, координирующим выполнение заданий и распределяющим работу по билд-агентам на основе различных критериев.
Ваши билд-агенты берут на себя работу по запуску сборок и выполнению тестов в соответствии с инструкциями, полученными от сервера непрерывной интеграции.
Рекомендуется отделять билд-сервер от билд-агентов, которые запускают сборки и выполняют тесты, по меньшей мере в продакшн-конфигурации, во избежание возникновения конфликта доступа к ресурсам и проблем с производительностью.
При использовании сервера непрерывной интеграции для организации логики этапа вашего пайплайна есть возможность задать особые условия и правила. Например, можно запускать определенные тесты коммитов в основную ветку, но не во время выполнения предкоммитной сборки на ветке разработки, или, скажем, контролировать количество сборок, которые могут одновременно обращаться к одной базе данных.
Одновременный запуск определенных заданий с использованием разных билд-агентов может повысить эффективность вашего пайплайна. Это полезно, когда необходимо запустить тесты на разных операционных системах или когда вы работаете с огромной кодовой базой, а тесты исчисляются сотнями тысяч, в этом случае единственный рациональный выход — параллельное выполнение. In the latter case, setting up a composite build will aggregate the results so you can treat the tasks as a single build step.
Билд-сервер, интегрированный с облачной инфраструктурой, такой как AWS, позволяет воспользоваться преимуществами гибких, масштабируемых ресурсов для выполнения сборок и тестов. Если у вас повышенные требования к инфраструктуре, поддержка контейнерных билд-агентов и интеграция с Kubernetes позволит эффективно распорядиться ресурсами сборки, независимо от их расположения — в облаке или в локальной инфраструктуре.
Важнейшей составляющей вашей бизнес-логики является определение того, что считать неудачным завершением сборки на каждом этапе CI/CD-пайплайна.
Your CI server should allow you to configure various failure conditions, which it will then apply and use to determine the status of a particular step and whether to proceed to the next stage of the pipeline.
Помимо очевидных неудачных завершений сборки (например, когда возвращается код ошибки или не выполняются тесты), можно задать и другие типы неудачных завершений на основе данных, собранных билд-сервером.
Скажем, это может быть уменьшение покрытия кода тестами по сравнению с предыдущей сборкой (а значит, для очередных изменений кода не были добавлены тесты) или увеличение количества проигнорированных тестов по сравнению с последней успешной сборкой.
На основании этих данных можно сделать вывод о возможном снижении качества кода. Задав эти метрики в качества триггера для неудачного завершения сборки и ограничив число пользователей, которым разрешено игнорировать эти сбои, можно добиться нужного сценария выполнения сборки.
Хотя название «сервер непрерывной интеграции» подразумевает, что его использование ограничивается лишь непрерывной интеграцией, большинство CI-серверов также поддерживают непрерывную доставку и развертывание.
После формирования артефактов сборки и выполнения исходного набора тестов во время этапа непрерывной интеграции следующим шагом является развертывание этих артефактов в тестовых средах для дальнейшего тестирования. После этого следует проверка рабочей версии всеми заинтересованными сторонами. Если на этом этапе нареканий нет, то за ним следует релиз.
As well as providing an artifact repository to store the outputs from each build so you can deploy them as needed, a CI/CD server can also store and manage parameters for each environment in your pipeline. В дальнейшем можно указать, должны ли ваши скрипты развертывания автоматически срабатывать в зависимости от результатов, полученных на предыдущем этапе.
Ключевой составляющей CI/CD-пайплайна является быстрая обратная связь по каждому этапу.
Билд-сервер может предоставлять информацию об очереди заданий, выдавать отчеты о сборках и тестах в режиме реального времени (прямо во время их выполнения), а также отображать состояние выполненных шагов сборки.
Настроив уведомления, вы и ваша команда будете оперативно узнавать о любых событиях, при этом интеграция с баг-трекерами дает возможность видеть исправления, которые содержит коммит, и оперативно выяснять причину неудачного завершения сборки. Из статистических данных можно получить полезные сведения для оптимизации пайплайна, а также определения условий в логике пайплайна.
Сервер непрерывной интеграции играет важную роль в работе вашего CI/CD-пайплайна, координируя и запуская различные стадии проекта, а также собирая и передавая данные по каждому этапу. Have a look at our Guide to CI/CD tools for tips on how to choose the right CI server for your organization.