Довідкова: як влаштований процес Continuous Integration

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

Довідкова: як влаштований процес Continuous Integration
/Flickr/ Altug Karakoc / CC BY / Фото змінено

Термін

Continuous Integration (безперервна інтеграція) - підхід до розробки додатків, що передбачає часте проведення збірок проекту та тестування коду.

Мета - зробити процес інтеграції передбачуваним і виявити потенційні баги та помилки на ранній стадії, щоб було більше часу на їх виправлення.

Вперше термін Continuous Integration з'явився 1991 року. Його ввів у вжиток автор мови UML Граді Буч (Grady Booch). Інженер представив концепцію CI як частину власної практики розробки. методу Буча. Він мав на увазі інкрементальне уточнення архітектури під час проектування об'єктно-орієнтованих систем. Граді не описав якихось вимог до безперервної інтеграції. Але пізніше у своїй книзі «Об'єктно-орієнтований аналіз та проектування з додаткамивін сказав, що завдання методики - прискорити випуск «внутрішніх релізів».

Історія

У 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-система розгортає код.

Загальну схему процесу можна представити так:

Довідкова: як влаштований процес Continuous Integration

Методологія CI пред'являє низку вимог до розробників:

  • Негайно виправляти проблеми. Цей принцип прийшов у CI із екстремального програмування. Виправлення багів - найпріоритетніше завдання розробників.
  • Автоматизувати процеси. Розробники та менеджери повинні постійно шукати «вузькі місця» у процесі інтеграції та усувати їх. Наприклад, часто «пляшковим шийкою» інтеграції виявляється Тестування.
  • Проводити складання якнайчастіше. Щодня, щоб синхронізувати роботу команди.

Труднощі впровадження

Перша проблема – високі операційні витрати. Навіть якщо компанія використовує відкриті CI-інструменти (про які ми поговоримо далі), їй все одно доведеться витратити гроші на підтримку інфраструктури. Проте рішенням можуть стати хмарні технології.

Вони спрощують складання різномаштабних комп'ютерних конфігурацій. Плюс компанії платять лише за використовувані ресурси, що допомагає заощадити на інфраструктурі.

Згідно з опитуваннями [стор.14 статті], безперервна інтеграція підвищує навантаження на співробітників компанії (принаймні спочатку). Їм доводиться освоювати нові інструменти, а колеги не завжди допомагають із навчанням. Тому доводиться розбиратися з новими фреймворками та сервісами «на ходу».

Третя складність – проблеми з автоматизацією. З нею стикаються організації з великим обсягом legacy-коду, який не покритий автоматизованими тестами. Це призводить до того, що код просто переписують перед повноцінним використанням CI.

Довідкова: як влаштований процес Continuous Integration
/Flickr/ theilr / CC BY-SA

Хто використовує

Одними з перших переваг методики оцінили ІТ-гіганти. Google використовує безперервну інтеграцію із середини 2000-х. CI впровадили для вирішення проблеми із затримками у роботі пошукової системи. Безперервна інтеграція допомогла оперативно виявляти та усувати неполадки. Наразі CI використовують усі підрозділи ІТ-гіганта.

Безперервна інтеграція допомагає і невеликим компаніям, а також інструменти CI використовують фінансові та медичні організації. Наприклад, у Morningstar сервіси безперервної інтеграції допомогли патчити вразливості на 70% швидше. А медична платформа Philips Healthcare спромоглася вдвічі прискорити тестування оновлень.

Інструменти

Ось кілька популярних інструментів для CI:

  • Дженкінс - Одна з найпопулярніших CI-систем. Вона підтримує понад тисячу плагінів для інтеграції з різними VCS, хмарними платформами та іншими сервісами. Jenkins використовуємо і ми в 1cloud: інструмент входить до нашої DevOps-системи. Він регулярно перевіряє Git-Гілку, призначену для тестування.
  • Buildbot - python-фреймворк для написання власних процесів безперервної інтеграції. Початкове налаштування інструменту досить складне, проте це компенсується широкими можливостями кастомізації. Серед переваг фреймворку користувачі виділяють його невисоку ресурсомісткість.
  • Конкурс CI — сервер Pivotal, який використовує контейнери Docker. Concourse CI інтегрується з будь-якими інструментами та системами контролю версій. Розробники зазначають, що система підходить для роботи у компаніях будь-яких розмірів.
  • Gitlab CI - Інструмент, вбудований в систему контролю версій GitLab. Сервіс працює у хмарі та використовує для конфігурації YAML-файли. Як і Concourse, Gitlab CI застосовує Docker-контейнери, які допомагають ізолювати різні процеси один від одного.
  • Кодування - Хмарний CI-сервер, який працює з GitHub, GitLab і BitBucket. Платформа не вимагає довгого початкового налаштування - Codeship доступні стандартні попередньо встановлені CI-процеси. Для невеликих (до 100 збірок на місяць) та open source проектів Codeship доступний безкоштовно.

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

Джерело: habr.com

Додати коментар або відгук