Хабрахабр

Справочная: как устроен процесс Continuous Integration

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


/ Flickr / Altug Karakoc / CC BY / Фото изменено

Термин

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

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

Его ввел в употребление создатель языка UML Гради Буч (Grady Booch). Впервые термин Continuous Integration появился в 1991 году. Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем. Инженер представил концепцию CI как часть собственной практики разработки — метода Буча. Но позже в своей книге "Object-Oriented Analysis and Design with Applications" он сказал, что задача методики — ускорить выпуск «внутренних релизов». Гради не описал каких-то требований к непрерывной интеграции.

История

В 1996 году CI переняли создатели методологии экстремального программирования (XP) — Кент Бек (Kent Beck) и Рон Джеффрис (Ron Jeffries). Непрерывная интеграция стала одним из двенадцати ключевых принципов их подхода. Основатели XP уточнили требования к методологии CI и отметили необходимость проводить сборку проекта несколько раз в день.

Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl. В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер (Martin Fowler). Утилиту создал коллега Мартина — Мэттью Фоммель (Matthew Foemmel).

Решение можно скачать и сегодня — оно распространяется под BSD-подобной лицензией. Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе.

С появлением софта для CI практику начали перенимать всё больше компаний. Согласно исследованию Forrester [стр.5 отчёта], в 2009 году 86% из пятидесяти опрошенных технологических компаний использовали или внедряли CI-методы.

В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.

Как это работает

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

Общую схему процесса можно представить следующим образом:

Методология CI предъявляет ряд требований к разработчикам:

  • Немедленно исправлять проблемы. Этот принцип пришёл в CI из экстремального программирования. Исправление багов — самая приоритетная задача разработчиков.
  • Автоматизировать процессы. Разработчики и менеджеры должны постоянно искать «узкие места» в процессе интеграции и устранять их. Например, часто «бутылочным горлышком» интеграции оказывается тестирование.
  • Проводить сборки как можно чаще. Раз в день, чтобы синхронизировать работу команды.

Сложности внедрения

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

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

14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Согласно опросам [стр. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу». Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением.

С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Третья сложность — проблемы с автоматизацией. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.


/ Flickr / theilr / CC BY-SA

Кто использует

Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.

Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. А медицинская платформа 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 доступен бесплатно.

Материалы из нашего корпоративного блога:

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»