CI/CD: що це, як пов’язано з DevOps, переваги, найкращі практики
Сучасну розробку програмного забезпечення вже складно уявити без конвеєра CI/CD. У початків ця тема досі порушує чимало питань. Тож у цій статті пояснюємо все, що варто знати про 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
DevOps — це доволі молода професія, яка з’явилась 5-8 років тому. Її назва утворена від слів Developers та Operations. Тобто DevOps-інженери ніби стоять між командами розробників та операційними командами та налагоджують їх взаємодію заради впровадження на проєктах принципів безперервних інтеграції, доставки, розгортання. Якщо ж говорити про більш низький рівень завдань, то команди DevOps виконують забезпечення інфраструктури для конвеєрів CI/CD, налагоджують автоматизацію, відстежують процеси на кожному з етапів та консультують стейкхолдерів.
Для роботи DevOps-інженеру потрібно розбиратися в багатьох сферах: від написання коду й тестування до конфігурації мереж. Проте зараз вже з’являються експерти зі спеціалізацією на окремих областях. Наприклад, LiveOps, які відповідають виключно за підтримку виробничого середовища, та SysOps, які адмініструють інфраструктуру. Ще можна згадати SecOps (розв’язують проблеми безпеки інфраструктури) та CloudOps (працюють з хмарною інфраструктурою). Втім, це тема окремої розмови. Тому радимо прочитати більш детально за цим посиланням, що таке DevOps.
Основні переваги CI/CD
Загалом вище вже було описано декілька плюсів від впровадження конвеєра CI/CD при розробці програмного забезпечення. Але в реальності їх набагато більше. Ми зібрали в цьому розділі лише найбільш значущі переваги безперервних інтеграції та доставки.
- Підвищення ефективності. Завдяки автоматизації девелопери витрачають менше часу на рутинні задачі з налаштування середовищ, виправлення помилок та деплою проєкту. Тобто у фахівців буде менше перемикання контексту, і вони зможуть зосередитися на основній роботі з кодом. А значить, через це зростає й продуктивність розробників на проєкті.
- Зменшення ризику дефектів. При традиційній моделі розробки до основного тестування «доживає» досить багато багів, зокрема й примітивних, пов’язаних з друкарськими помилками та неуважністю. Це відвертає зайві ресурси QA-команд і розробників, особливо якщо помилки потрапляють до релізу. З CI/CD виявлення таких багів відбувається майже одразу після їх появи в коді.
- Швидший деплой продукту. Автоматизація — це прискорення. Але у випадку безперервної доставки виграш не просто у виконанні задач інструментами, а не людьми. Важливіше, що конвеєри CI/CD дозволяють випускати нові функції одразу по готовності. Класичні релізи відбуваються далеко не кожний місяць, а з безперервним розгортанням оновлення можна запускати хоч щодня.
- Збільшення логів. За будь-якою моделлю розробки програмного забезпечення має бути моніторинг оновлення й тестування кода, деплою, перфомансу. Але в цій практиці все виходить на новий рівень. Її не уявити без інструментів, які фіксують буквально будь-які зміни у поведінці команд та продукту. Це дозволяє набагато якісніше розуміти, які проблеми з’являються, де та чому.
- Швидкий відкат. Завдяки безперервним інтеграції та доставці можна легко повернутися до попередньої версії, якщо щось при оновленні пішло не так. Неважливо, в чому саме буде проблема — в конфлікті в новому коді або, наприклад, у роботі виробничого середовища. Задля того, щоб відкотитися до стабільної збірки, потрібно буде натиснути буквально декілька клавіш.
- Спрощення планування. Традиційні моделі не є гнучкими. Через це командам розробки та операцій доводиться витрачати багато часу на побудову планів та створення запасних сценаріїв, якщо щось піде не так. Конвеєр CI/CD на цьому фоні є більш привабливим рішенням. В його природі вже закладена здатність адаптуватися під мінливі умови сучасного бізнесу та появу нових функцій.
- Покращені перевірки коду. Безперервне тестування — це те, про що мріє, мабуть, кожен власник продукту. Адже тоді можна бути впевненим, що більшість помилок виявлені ще на стадії розробки програмного забезпечення. При цьому можна легко реалізувати й інтеграційні тести, й модульні тести, і будь-які інші, всі вони будуть автоматизовані.
- Економічна доцільність. Випуск коду відбувається швидше, оптимізація робочих процесів посилюється, якість програмного забезпечення підвищується. Логічно, що все це позитивно позначається на економічних показниках. Завдяки впровадженню таких підходів вартість розробки знижується. При цьому сам продукт має більше шансів стати успішним серед користувачів.
Топ найкращих практик CI/CD
Побудова, використання та моніторинг конвеєра CI/CD є комплексною задачею. Тому перерахувати всі-всі best practices в одній оглядовій статті в принципі неможливо. Але описати декілька найбільш популярних, корисних та цікавих порад — цілком реально. Хто знає, може, саме вони трапляться вам серед запитань девопсів на співбесіді?
Об’єднуйте код щодня
Розробникам не варто чекати на злиття до основної гілки великої партії змін в коді. Хай це будуть зовсім маленькі фрагменти нового коду, але так ви зможете зменшити складність конфліктів. Також не треба створювати безліч гілок під окремі задачі. Це ускладнює контроль версій. Але й не слід занадто часто генерувати вихідний код для релізу. Це може засмічувати виробниче середовище.
Максимально автоматизуйте тестування
Ручне втручання людини в будь-які задачі з розробки програмного забезпечення — це завжди ризик помилок. Особливо критично це в безперервному тестуванні. Слід продумати можливість автоматизації якомога більшої кількості тестів. І це не лише завдання для QA. Команди DevOps мають також долучитися до цього процесу. Завдяки їх знанням вони можуть допомогти у створенні принципово нових тестових сценаріїв.
Запускайте паралельні тести
Конвеєри CI/CD мають бути саме конвеєрами — а тому одночасне виконання схожих задач є нормальною практикою. Виконуйте одразу по декілька перевірок змін в коді та економте час. Якщо ресурси інфраструктури обмежені, то відсортуйте задачі. Краще починати з простих та легких тестів, що спрацює на підвищення ефективності робот. А ще можна залучити хмарні інфраструктури для проведення автоматизованого тестування.
Забезпечуйте чистоту тестового середовища
Під кожну ітерацію перевірок варто створювати нові контейнери. Тоді на результати ваших автоматизованих тестів не будуть впливати остаточні ефекти від попередніх запусків. Чисті одноразові середовища зменшують вплив різних хост-середовищ на кінцеві результати. А ще такі контейнери дозволять вам інтегрувати різні компоненти з використанням стандартних API.
Використовуйте контроль версій
Зазвичай це системи на кшталт GitHub, GitLab, BitBucket. Тому завжди при виявленні на тестах помилок чи конфліктів слід одразу відкотити проєкт до стабільної версії. Так ви можете проаналізувати все, виявити причину та не зупинити всі інші процеси.
Продумайте перенесення коду
Міграція нового коду між середовищем розробки та виробничим середовищем є доволі складною та нудною задачею. Це відриває розробників від основної роботи та несе в собі чимало ризиків. Тому краще спростити цей процес завдяки тій саме автоматизації. Задля цього можна використовувати спеціальні скрипти для перенесення коду та додавати їх до інфраструктури на проєкті.
Уникайте ухилення від стандартів CI/CD
Принципи безперервної інтеграції, доставки та розгортання мають стосуватися всіх без виключення задач. Цей механізм має бути одностороннім та однопоточним. Ви маєте бути впевненими, що жодна таска в роботі зі змінами в коді не виконується поза межами побудованого конвеєра. В іншому випадку завжди буде ризик, що якісь проблеми перейдуть на інші рівні та потраплять на продакшен.
Відстежуйте фідбеки
Безперервними мають бути не лише згадані процеси, але й отримання зворотного зв’язку. Тільки постійний збір даних про роботу коду та застосунку в цілому дозволить вам гарантувати надійну роботу автоматизації та команд розробки та операцій. При цьому всі звіти мають бути структурованими, с чіткою ціллю та корисними висновками. Тоді ви зможете дійсно покращувати й безперервне тестування, і написання коду.
Гарантуйте прозорість процесів
Це одна із запорук успішної реалізації CI/CD як такого. Без відкритості неможливо побудувати якісні комунікацію і взаємодію різних фахівців, забезпечити надійність тестів та загальну швидкість розробки. Тому DevOps-інженери мають підтримувати прозорість між різними командами. Задля цього можна, наприклад, надавати регулярні апдейти за результатами тестів, ланцюжку процесів тощо.
Підбирайте оптимальні інструменти
Яким би якісним не був конвеєр та як би відповідально не працювали всі залучені спеціалісти, безперервна інтеграція та безперервна доставка програмного забезпечення можуть не дати результату — якщо ви використовуєте не найкращі тулзи. Слід детально продумати, з чим працювати. Для кожної задачі в CI/CD є багато потужних сервісів і програм. Тому ви завжди знайдете те, що найкраще відповідає саме вашим потребам.
Інструменти DevOps
Перерахувати всі можливі тулзи для роботи із середовищем DevOps неможливо — їх дуже багато. Але для прикладу варто перерахувати декілька найбільш популярних програм, які дозволяють оптимізувати виконання основних завдань в роботі команд DevOps:
- Ansible. Тулза допомагає управляти конфігураціями та масштабувати їх для сотень серверів, середовищ і застосунків. При цьому для віддалених пристроїв Ansible підтримує SSH, що є не в кожному аналогу. Управляти інструментом легко — завдяки декларативній мові розмітки та YAML.
- Terraform. З цим сервісом можна швидко створювати інфраструктуру та налаштовувати її в автоматичному режимі. Це можуть бути віртуальні машини, сховища, балансувальники навантаження, хмарні сервіси від AWS, Azure і GCP. А для управління використовується декларативна мова з HCL та JSON.
- Jenkins. Опенсорсний інструмент для спрощення імплементації CI/CD на проєкті. Він має безліч інтеграцій з багатою кількістю тулзів та сервісів через систему плагінів. Це й системи контролю версій, і тулзи для деплою у різні типи середовищ, і підтримка фреймворків для тестувальників, і багато іншого.
- Docker. Платформа спрощує безперервне розгортання та управління різних середовищ. Вона дозволяє буквально однією командою упаковувати застосунки у контейнери, в яких є все необхідне для запуску: від залежностей та бібліотек до конфігураційних файлів.
- Kubernetes. Сервіс оркестрації — автоматизованого управління, контролю та відстеження будь-якої кількості контейнерів. Цей інструмент підтримує роботу з Terraform, Jenkins та Docker (зокрема й з Docker-образами). Також Kubernetes працює на AWS, Azure та GCP.
Звісно, тільки цими інструментами робота інженера не обмежується. Стануть у пригоді й інші тулзи, навички адміністрування операційних систем Linux та Windows, знання Python, Bash та розуміння принципів роботи таких хмар, як AWS, Azure або GCP. Хоча, як кажуть досвідчені експерти, важливо знати не кнопки, а принципи. Тоді ви легко зможете освоювати нові інструменти, які з’являються у цій сфері мало не щодня.
Підписуйтеся на наші соцмережі
