Раніше ми про Continuous Integration (CI). Продовжимо з Continuous Delivery. Це зведення методів розробки ПЗ. Він допомагає переконатися у готовності коду до розгортання.
/ Pixabay / /
Історія
Словосполучення continuous delivery можна було побачити ще в від 2001 року на початку списку основних принципів: "Пріоритет - вирішення завдань замовника за допомогою безперервного постачання актуального ПЗ".
У 2010 році Джез Хамбл (Jez Humble) та Девід Фарлі (David Farley) випустили за Continuous Delivery. За задумом авторів, CD доповнює підхід і дозволяє спростити підготовку коду до розгортання.
Після публікації книги підхід почав набирати популярності і всього за пару років став практично загальноприйнятим. Згідно , проведеному серед більш ніж 600 розробників та ІТ-менеджерів у 2014 році, 97% технічних керівників та 84% програмістів були знайомі з Continuous Delivery.
Зараз цей підхід залишається одним із найпопулярніших. За даними дослідження 2018 року, до якого залучили співтовариство IT-фахівців DevOps and Jenkins Community, його половина більш ніж тисячі опитаних респондентів.
Як працює Continuous Delivery
Базис CD - готовність коду до розгортання. Для виконання цього завдання використовується автоматизація процесу підготовки до релізу. Він має бути стандартним для різних середовищ розробки, що допоможе швидше знаходити слабкі місця та оптимізувати їх. Наприклад, пришвидшувати тестування.
Приклад процесу Continuous Delivery виглядає так:
Якщо автоматизацію перших двох етапів відповідає підхід Continuous Integration, то наступні два — Continuous Delivery. Стабільність процесу забезпечується у тому числі і за рахунок систем . Вони моніторять зміни в інфраструктурі, базах даних та залежностях. Саме розгортання може бути автоматизовано, а може виконуватися вручну.
До процесу пред'являються такі вимоги:
- Доступність інформації про готовність до виходу в production-середовище та готовність до безпосереднього релізу (CD-інструменти тестують код та дають можливість оцінити ефект від змін у релізі).
- Загальна відповідальність за фінальний товар. Команда продукту – менеджери, розробники, тестувальники – думають про результат, а не лише про свою зону відповідальності (результат – робочий реліз, доступний для користувачів продукту).
У CD зазвичай застосовують , а для збору думок клієнтів - принцип . Нову функцію спочатку випускають для невеликого сегмента користувачів - їхній досвід взаємодії з продуктом допомагає знайти недоліки та баги, які не помітили при внутрішньому тестуванні.
У чому вигода
Continuous Delivery допомагає спростити розгортання коду, що позитивно впливає на продуктивність та знижує ймовірність емоційного вигоряння працівників. Зрештою, це знижує і загальні витрати на розробку. Наприклад, CD допоміг одній з команд HP такі витрати на 40%.
Крім цього, згідно з дослідженням 2016 року (сторінка 28 ) - Компанії, які впровадили CD, на 50% швидше вирішують проблеми з ІБ, порівняно з тими, хто не використовують підхід. Певною мірою таку відмінність можна пояснити роботою інструментів автоматизації процесу.
Ще один плюс – прискорення випуску релізів. У фінській студії розробки безперервне постачання збільшити швидкість збирання коду на 25%.
Потенційні складнощі
Перша та основна проблема – необхідність перебудовувати звичні процеси. Щоб показати користь нового підходу, варто переходити на CD поступово, починаючи не з трудомістких додатків.
Друга потенційна проблема – велика кількість гілок коду. Наслідок «розгалуження» – часті конфлікти та чергові втрати великої кількості часу. Можливе рішення – підхід .
Зокрема, в деяких компаніях основні складності виникають із тестуванням — на нього йде занадто багато часу. Результати тестів часто доводиться аналізувати вручну, але можливим рішенням можливо розпаралелювання тестів на перших етапах впровадження CD.
Також слід навчити співробітників працювати з новими інструментами — попередній лікнеп заощадить розробникам сили та час.
/Flickr/ /
Інструменти
Наведемо кілька відкритих інструментів для Continuous Delivery:
- - сервер для безперервного постачання на Java та JRuby on Rails. Дозволяє контролювати весь процес постачання програми: build-test-release. Інструмент розповсюджується за ліцензією Apache 2.0. На офіційному сайті можна знайти .
- - Фреймворк для створення скриптів, що автоматизують розгортання додатків на Ruby, Java або PHP. Capistrano здатний виконувати команди на віддаленій машині, підключаючись до неї SSH. Працює з іншими інструментами безперервної інтеграції та постачання, наприклад, CI-сервером Integrity.
- - Мультиплатформний інструмент, що автоматизує весь цикл розробки додатків. Gradle працює з Java, Python, C/C++, Scala та ін. Є інтеграція з Eclipse, IntelliJ та Jenkins.
- - платформа для CD мовою Go. Drone можна розгорнути on-premise або у хмарі. Інструмент побудований на базі контейнерів та використовує YAML-файли для керування ними.
- - платформа для безперервного постачання коду в мультихмарних системах. Розроблено в Netflix, велику роль у розробці інструменту відіграли інженери Google. Інструкцію з встановлення ви .
Що почитати у нашому корпоративному блозі:
Джерело: habr.com