Справочная: как устроен процесс Continuous Integration
Сегодня мы обратимся к истории термина, обсудим сложности внедрения CI и приведем несколько популярных инструментов, которые помогут с ним работать.
/ Flickr / Altug Karakoc / CC BY / Фото изменено
Термин
Continuous Integration (непрерывная интеграция) — подход к разработке приложений, подразумевающий частое проведение сборок проекта и тестирование кода.
Цель — сделать процесс интеграции предсказуемым и обнаружить потенциальные баги и ошибки на ранней стадии, чтобы было больше времени на их исправление.
Впервые термин Continuous Integration появился в 1991 году. Его ввел в употребление создатель языка UML Гради Буч (Grady Booch). Инженер представил концепцию CI как часть собственной практики разработки — метода Буча. Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем. Гради не описал каких-то требований к непрерывной интеграции. Но позже в своей книге «Object-Oriented Analysis and Design with Applications» он сказал, что задача методики — ускорить выпуск «внутренних релизов».
История
В 1996 году CI переняли создатели методологии экстремального программирования (XP) — Кент Бек (Kent Beck) и Рон Джеффрис (Ron Jeffries). Непрерывная интеграция стала одним из двенадцати ключевых принципов их подхода. Основатели XP уточнили требования к методологии CI и отметили необходимость проводить сборку проекта несколько раз в день.
В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер (Martin Fowler). Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl. Утилиту создал коллега Мартина — Мэттью Фоммель (Matthew Foemmel).
Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе. Решение можно скачать и сегодня — оно распространяется под BSD-подобной лицензией.
С появлением софта для CI практику начали перенимать всё больше компаний. Согласно исследованию Forrester [стр. 5 отчёта], в 2009 году 86% из пятидесяти опрошенных технологических компаний использовали или внедряли CI-методы.
Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.
Как это работает
Основу непрерывной интеграции составляют два инструмента — система контроля версий и CI-сервер. Последний может быть как физическим устройством, так и виртуальной машиной в облачной среде. Разработчики один или несколько раз в день загружают новый код. CI-сервер автоматически копирует его со всеми зависимости и выполняет сборку. После — запускает интеграционные и юнит-тесты. Если тесты проходят успешно, то CI-система разворачивает код.
Общую схему процесса можно представить следующим образом:
Методология CI предъявляет ряд требований к разработчикам:
- Немедленно исправлять проблемы. Этот принцип пришёл в CI из экстремального программирования. Исправление багов — самая приоритетная задача разработчиков.
- Автоматизировать процессы. Разработчики и менеджеры должны постоянно искать «узкие места» в процессе интеграции и устранять их. Например, часто «бутылочным горлышком» интеграции оказывается тестирование.
- Проводить сборки как можно чаще. Раз в день, чтобы синхронизировать работу команды.
Сложности внедрения
Первая проблема — высокие операционные расходы. Даже если компания использует открытые CI-инструменты (о которых мы поговорим дальше), то ей все равно придется потратить деньги на поддержку инфраструктуры. Однако решением могут стать облачные технологии.
Они упрощают сборку разномасштабных компьютерных конфигураций. Плюс компании платят только за используемые ресурсы, что помогает сэкономить на инфраструктуре.
Согласно опросам [стр. 14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».
Третья сложность — проблемы с автоматизацией. С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.
/ Flickr / theilr / CC BY-SA
Кто использует
Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.
Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.
Инструменты
Вот нескольких популярных инструментов для CI:
- Jenkins — одна из самых популярных CI-систем. Она поддерживает более тысячи плагинов для интеграции с разными VCS, облачными платформами и другими сервисами. Jenkins используем и мы в 1cloud: инструмент входит в нашу DevOps-систему. Он регулярно проверяет Git-ветку, предназначенную для тестирования.
- Buildbot — python-фреймворк для написания собственных процессов непрерывной интеграции. Первоначальная настройка инструмента довольно сложна, однако это компенсируется широкими возможностями кастомизации. Среди достоинств фреймворка пользователи выделяют его невысокую ресурсоёмкость.
- Concourse CI — сервер от Pivotal, который использует контейнеры Docker. Concourse CI интегрируется с любыми инструментами и системами контроля версий. Разработчики отмечают, что система подходит для работы в компаниях любых размеров.
- Gitlab CI — инструмент, встроенный в систему контроля версий GitLab. Сервис работает в облаке и использует для конфигурации YAML-файлы. Как и Concourse, Gitlab CI применяет Docker-контейнеры, которые помогают изолировать разные процессы друг от друга.
- Codeship — облачный CI-сервер, который работает с GitHub, GitLab и BitBucket. Платформа не требует долгой первоначальной настройки — в Codeship доступны стандартные предустановленные CI-процессы. Для небольших (до 100 сборок в месяц) и open source проектов Codeship доступен бесплатно.
Материалы из нашего корпоративного блога:
