CI vs CD vs CD: різниця підходів і чому вони важливі

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Артур, я — Front-end розробник у компанії ISsoft Ukraine. Я працюю у цій сфері трохи більше чотирьох років і на своєму досвіді застав декілька підходів до організації середовища застосунків, їхнього тестування та розгортання готового продукту в публічний доступ, щоб надати актуальний функціонал для користувачів.

Тож у цій статті я хочу більш детально розглянути різні практики провадження змін, що існують сьогодні в програмуванні. Поговоримо, що таке Continuous Integration, Delivery та Deployment, у чому їхня різниця та чому ці підходи є такими важливими.

Що таке Continuous Integration, Delivery та Deployment

У минулому розробники могли витрачати багато часу, працюючи наодинці, а потім об’єднували свої зміни в основну гілку після їхнього виконання. Це призводило до того, що дефекти накопичувалися протягом тривалого періоду без усунення, а інтеграція змін коду була складною та трудомісткою.

Через ці міркування було важче оперативно надавати клієнтам оновлення. Тому на світ почали з’являтися нові підходи щодо внесення змін, колаборації та розподілу «обов’язків» для команд.

Continuous Integration, Delivery та Deployment — процеси, що дозволяють полегшити впровадження змін у застосунку для їхнього швидкого розгортання у середовище (prod, staging, dev та інші). Частіше всього, це реалізується за допомогою створення пайплайнів, що автоматизують певні повторювані дії.

На схемі показано, які процеси належать до кожного підходу. І хоча на ній підходи зображені разом, найчастіше з Continuous Delivery та Deployment обирають один, який підходить до внутрішніх процесів розробки найбільше. Тож поговоримо про ці підходи і більш детально розглянемо кожен з них.

Continuous Integration

Continuous Integration — це процес об’єднання змін у коді від декількох розробників в один спільний проєкт, що має виконуватись якомога частіше. Загалом цю задачу покладають на систему контролю версій. А чому це необхідно?

Зараз більшість репозиторіїв налаштовано так, що під час внесення будь-яких змін у систему контролю версій ми запускаємо ланцюжок процесів, що мають перевірити базову працездатність коду — тестування, правила форматування, компіляція останньої версії коду для перевірки, а чи нема в нових змінах помилок, що «завалять» потенційний білд.

Тож усі ці процеси направлені на те, щоб раніше виявляти потенційні баги, покращувати якість кінцевого продукту та скоротити час верифікації та релізу нового функціоналу. І хоча неможливо уникнути виникнення багів, Continuous Integration може допомогти шляхом їх виявлення та усунення. Це головна причина, чому сьогодні бізнес відходить від застарілих підходів до СІ.

Після кроку Continuous Integration зміни рухаються до фази Continuous Delivery та розгортання для доступу кінцевих користувачів. Зміни коду проходитимуть через численні виправлення та збір фідбеку, перш ніж потрапити в робоче середовище, тоді як у разі, коли наявний процес Continuous Delivery, команда вирішує, як та коли розгортати нові оновлення для клієнтів.

Процес розгортання може піти на крок далі завдяки Continuous Deployment — повністю автоматизованому процесу. Ці дві концепції не мають однакового визначення, але вони мають спільну мету автоматизації та оптимізації процесу розробки. Іноді Continuous Delivery та Deployment йдуть разом, щоб максимально використати переваги обох практик.

Розглянемо приклад: у більшості проєктів, у яких я брав участь, були налаштовані автоматичні пайплайни, що виконувались на кожен коміт. Я створював гілку у GitHub, вносив зміни в код, та, як тільки робота була завершена, я пушив код у загальний репозиторій і Jenkins запускав пайплайн з перевіркою форматування, тестами та білдом проєкту.

Якщо на якійсь із цих стадій була виявлена помилка, результат цього пайплайну відображався на сторінці пул реквесту та не дозволяв мерджити гілки. Тож помилка мала бути виправлена, і вже новий успішний пайплайн вважався одним з обов’язкових пунктів для закриття пул реквесту. Так, ми отримали функціонал — протестований і перевірений, — для того, щоб передати його наступній фазі.

Continuous Delivery та Deployment

Розглянувши перший крок процесів автоматизації, перейдемо до стадії, коли ми вже маємо протестований, якісний функціонал, який має бути в майбутньому релізі. І тут в гру вступає Continuous Delivery. Що ж це за магічне словосполучення?

По суті, це автоматизоване впровадження останньої версії продукту в Production та інші середовища. Але до цього код має пройти автоматизовані Unit-, Integration- та System-тестування, що проводяться на стадії інтеграції.

Тобто поєднуючи два процеси, наведені вище, ми можемо отримати протестований функціонал одразу розгорнутим у середовищі за допомогою пайплайну в один клік. Звичайно ж, рішення про розгортання нового релізу має ухвалюватися людиною, але підготовкою займається система.

Розглянемо інший процес, який називається Continuous Deployment. Це наступний крок у розгортанні змін на середовищі. По своїй суті, continuous deployment — це практика у розробці, коли будь-які зміни якнайшвидше потрапляють у production-середовище.

На меті цей процес ставить лише одне: релізити зміни, які роблять розробники, якомога частіше й швидше доставляти їх кінцевим користувачам. Тобто коли випускається новий реліз, пайплайн підхоплює його, верифікує, чи всі перевірки виконані, та створює білд, який буде розгорнутий одразу на Production.

Звернімо увагу, що людина зовсім не залучена в цьому процесі, і тільки якщо «зваляться» тести, код не буде розгорнуто в середовищі.

У чому ж різниця між Continuous Delivery та Deployment

Часто ці два процеси ставлять на один щабель і наївно кажуть, що це синонімічні поняття. Насправді між ними є значущі відмінності, які ваше пильне око могло вже помітити.

Якщо коротко, то Continuous Delivery спрямований на підтримку коду в стані, коли він завжди готовий піти в реліз та бути розгорнутим у Production, але лише за вказівкою людини, що контролює цей процес.

На противагу цьому Continuous Deployment скорочує цей процес, та за першої ж можливості, коли тест-плани успішні, розгортає зміни в середовищі.

Який із цих планів кращий? Усе залежить від потреб конкретного продукту: якщо необхідно швидко доставити зміни кінцевому користувачу та скоротити так званий feedback loop: Deployment підходить сюди найкраще; якщо процес впровадження коду для кінцевих користувачів має бути проконтрольований та верифікований вручну перед релізом: Delivery — ваш вибір.

Але є певні продукти, які вимагають того чи іншого підходу. Наприклад, для вебплатформ або застосунків матиме сенс проходження Quality Assurance до того, як потрапити в руки кінцевих користувачів, тому тут буде використовуватись підхід Continuous Delivery, а от для монолітних застосунків або певних баз даних найкращим варіантом буде Deployment.

Але й спільного у Continuous Deployment та Continuous Delivery достатньо. Обидва підходи залежать від інфраструктури проєкту та моніторингових систем, що дозволяють забезпечити підтримку продукту та виявити більшість помилок ще до релізу певних змін.

Наведу порівняльну таблицю для Deployment та Delivery

Тож із визначенням цих двох процесів ми розібрались, тепер розглянемо приклад. Згадаймо, що в розділі про Continuous Integration ми вже отримали готовий білд, що пройшов автоматизоване тестування. Що ж далі?

Тепер команді QA треба перевірити, чи правильно той функціонал працює з точки зору бізнес-логіки застосунку. Тож, маючи готовий білд з новою фічею, наш тімлід регулярно оновлював Staging-середовище до останньої версії.

Усе це реалізовувалось за допомогою таких самих пайплайнів у Jenkins. Тобто, по суті, цей сервер автоматизації надає можливість вказати, що і куди має бути встановлене. Можна обрати будь-який з останніх успішних білдів. І як тільки функціонал конкретного релізу протестовано — виконані всі правки, знайдені на стадії тестування функціоналу, закриті всі тікети з відповідного релізу — ми можемо надати цей функціонал «на загал» користувачів.

На жаль, я не маю досвіду роботи в середовищі, де був реалізований Continuous Deployment, тому не можу розкрити всю «кухню» із середини, але, судячи з опису процесів, що закладені в цей підхід, відмінність тільки в тому, хто ухвалює рішення щодо встановлення оновлень у середовища.

Висновок

Тож ми з вами розглянули три основні можливі етапи розгортання змін та функціоналу, що розробляється. Зберемо все до купи: Сontinuous Іntegration — процес автоматизованого тестування та верифікації, що дозволяє на кожну зміну у коді запустити тестування певних частин або всього застосунку.

Continuous Delivery та Deployment — це процес отримання протестованого функціоналу, виправлених помилок тощо в робочому середовищі.

Також ми побачили основну різницю між підходами Continuous Delivery та Deployment — перший зосереджений на тому, щоб функціонал був завжди готовий до релізу та очікує команди на розгортання його в середовищі. А другий одразу розгортає білд зі змінами одразу після проходження тестів у автоматичному режимі.

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