Сегодня мы обратимся к истории термина, обсудим сложности внедрения 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).
Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.
Основу непрерывной интеграции составляют два инструмента — система контроля версий и CI-сервер. Последний может быть как физическим устройством, так и виртуальной машиной в облачной среде. Разработчики один или несколько раз в день загружают новый код. CI-сервер автоматически копирует его со всеми зависимости и выполняет сборку. После — запускает интеграционные и юнит-тесты. Если тесты проходят успешно, то CI-система разворачивает код.
Общую схему процесса можно представить следующим образом:
Методология CI предъявляет ряд требований к разработчикам:
Первая проблема — высокие операционные расходы. Даже если компания использует открытые CI-инструменты (о которых мы поговорим дальше), то ей все равно придется потратить деньги на поддержку инфраструктуры. Однако решением могут стать облачные технологии.
Они упрощают сборку разномасштабных компьютерных конфигураций. Плюс компан��и платят только за используемые ресурсы, что помогает сэкономить на инфраструктуре.
Согласно опросам [стр.14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».
Третья сложность — проблемы с автоматизацией. С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.
/ Flickr / theilr / CC BY-SA
Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.
Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.
Вот нескольких популярных инструментов для 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 доступен бесплатно.
