CI/CD: що це, як пов’язано з DevOps, переваги, найкращі практики
Сучасну розробку програмного забезпечення складно уявити без конвеєра CI/CD. Однак у початків ця тема досі викликає чимало питань. У цій статті експерти NIX пояснююють усе, що важливо знати про CI/CD: від основних понять до інструментів та best practices.
Що таке CI/CD
CI/CD — це набір методик, які дозволяють значною мірою автоматизувати процеси розробки програмного забезпечення, тестування коду і, що найголовніше, розгортання й доставки продукту та його оновлень до кінцевих користувачів. Термін утворено скороченням від Continuous Integration, безперервна інтеграція, та Continuous Delivery, безперервна доставка. Ці два поняття є ключовими для всієї подальшої автоматизації.
Для її забезпечення команди розробників будують так звані конвеєри CI/CD. Вони містять чітко прописані сценарії по кожному кроку: від створення коміту та зміни кодудо злиття в основну гілку та деплою у виробниче середовище й надалі. У деталях конвеєр CI/CD може відрізнятися від проєкту до проєкту: залежно від програмного забезпечення, яке створюють розробники, самої команди розробників, наявних ресурсів тощо. Але загалом можна окреслити базову схему циклу розробки:
1. План робіт
Менеджерська, девелоперська та операційна команди визначають мету й методи дій та інструменти для їх втілення. Це може стосуватися як цілих спринтів, так і окремих тасок на нові функції.
2. Розробка
Ключова частина роботи — безпосередньо внесення змін у коді відповідно до узгодженого плану із запитами на злиття та їх поступовою обробкою іншими розробниками.
3. Збірка
Коли новий код вже готовий, девелопери створюють білд. Тобто на етапі збирання вони заливають нововведення у вихідний код, що обов’язково фіксується у системі контролю версій.
4. Тестування
CI/CD стосується не лише розробників — QA-команди теж повною мірою залучені в цій схемі. В ідеалі це мають бути максимально комплексні та, що важливіше, автоматизовані тести коду.
5. Розгортання або деплой оновленого програмного забезпечення
Інколи навіть говорять про необхідність ще й Continuous Deployment, безперервного розгортання, але про це детальніше поговоримо далі.
6. Моніторинг
Після запуску слід контролювати коректність роботи сервісу або застосунку. Для цього будують систему збору фідбеку. Ця інформація допомагає виправляти помилки, оптимізувати код та додавати фічі. Що, власне, й повертає до першого пункту.
В дрібницях залежно від особливостей проєкту можуть бути відмінності. Але головне — це саме повторюваність процедур по колу. Розробка програмного забезпечення має йти за принципами безперервної інтеграції, тестування та доставки. Не дарма ж для неформального логотипа цієї практики обрали саме знак нескінченості.
У чому суть процесу CI/CD
Хоча цей підхід набув популярності лише в останні 10-15 років, його суть — не нова. Вже давно команди розробників використовують системи контролю версій коду на кшталт SVN, Git та інших. Але вони забезпечують лише безперервну інтеграціюнового коду. Сьогодні цього вже замало. Потрібно ще й автоматично та безперервно збирати та доставляти код у вигляді готового до використання програмного забезпечення або сервісу. Саме поєднання CI та CD дозволяє досягти високоїшвидкості розробки та гарантувати повторюваність процесів, підвищити якість програмного забезпечення та безпеку його оновлень. І все це — з мінімальним ручним втручанням людини.
Варто окреслити: загалом CI/CD не є обов’язковим для життєвого циклу розробки програмного забезпечення як такого. Багатьом розробникам взагалі вистачає простої системи контролю версій (хоча такі сервіси, як GitHub та GitLab вже надають можливості для CI/CD). Чимало фахівців вважає, що без цього автоматизованого процесу важко побудувати насамперед великі та складні проєкти з постійними додаванням та оновленнями фіч і змінами в коді. А ось маленькі продукти ніби можна створювати без безперервної інтеграції та безперервної доставки. В цьому, звичайно, є певна логіка. Проте автоматизація розробки, тестування та процесу розгортаннянезалежно від масштабу проєкту все одно приносить свою користь — наприклад, допомагає швидше виходити на ринок.
Відмінності між CI та CD
Хоча про цей набір методик у розробці постійно говорять як про CI/CD, все ж потрібно розділяти між собою безперервну інтеграцію та безперервну доставку. Це дозволить командам розробки та операцій організувати більш коректну роботу з кодом на всіх етапах побудови та функціонування конвеєрів CI/CD.
- CI, Continuous Integration. За класичною моделлю розробки програмного забезпечення кілька розробників працюють над змінами в коді незалежно один від одного, і лише коли все готово — об’єднують частини в єдину систему. Але це має багато проблем. По-перше, випуски коду треба довго чекати. По-друге, майже завжди виникають збої коду. Це потребує глибоких інтеграційних тестів і виправлення помилок, що теж може викликати конфлікт частин коду. Тож програмне забезпечення оновлюється повільно, постійно з’являються баги, задоволення клієнтів та юзерів знижується. Безперервна інтеграція діє за іншим принципом. Кожен розробник у команді працює у власній гілці коду, створеній в системі контролю версій під окрему задачу, і по готовності заливає написаний код до основної гілки. Систему доповнює автоматизоване тестування для миттєвого виявлення конфліктів, тож розробники одразу виправляють помилки. А в центрі системи — сервер збірки, який і керує CI-процесами.
- CD, Continuous Delivery. Як і у випадку з безперервною інтеграцією коду, почати варто з опису класичної моделі доставки програмного забезпечення. В ній за виконання цього етапу життєвого циклу розробки відповідає операційна команда, яка фактично вручну виконує всі потрібні процедури з кодом та середовищами. При такому підході процес розгортання стає дуже складною та довгою задачею, з безліччю контрольних списків і виправленням знайдених проблем. Конвеєр безперервної доставки позбавлений цих недоліків. Розробникам треба за допомогою спеціальних інструментів налаштувати систему практично всього раз, і далі все зробить автоматизація. Відповідно до побудованих CD-процесів система упакує вихідний код з робочого репозиторію, розгорне його на тестовому середовищі, оцінить коректність роботи нового коду та за відсутності проблем і після підтвердження з боку людини відправить все вже на центрального сховища програмного забезпечення.
Хоча конвеєр CI/CD будують саме на основі безперервних інтеграції та доставки, деякі розробники все більше радять переходити на наступний рівень ще одного CD — вже від Continuous Deployment, безперервне розгортання. В такому випадку будь-які зміни в коді, навіть якщо це дуже маленькі партії, одразу після успішного проходження автоматизованих тестів розгортаються на виробниче середовище. Це дозволяє скоротити до мінімуму час отримання фідбеку від користувачів. Адже команді розробників більше не треба очікувати на спільні релізи.
Але практика розробки програмного забезпечення показує: безперервне розгортаннядостатньо складно реалізувати. Операційні команди мають налагодити максимально безшовну автоматизацію буквально всіх процесів та вийти на рівень формування особливої культури роботи з кодом на проєкті. Це потребує не аби яких зусиль та контролю. Втім, така робота може виявитися цілком виправданою.
Про те, як CI/CD пов’язаний з DevOps, які підходи та інструменти радять використовувати експерти NIX для роботи із середовищем DevOps — читайте у продовженні статті за посиланням.
