Тема CI/CD включає багато технологій зі сфери DevOps і охопити їх всі в одній статті — неможливо. Тож вважайте, що цей матеріал — така собі “оглядова екскурсія”. І вашими гідами у світ CI/CD стануть Сергій Філімонов, DevOps Lead у NIX, та Микита Андрєєв, Senior DevOps Engineer у NIX. 

Про що ви дізнаєтеся: як впровадити CI/CD-процес у своїй команді та як його застосовувати на практиці. І, звісно, ми не оминемо bad practices!

Що таке CI/CD

CI/CD є поширеною DevOps-практикою. CI (Continuous Integration) — це неперервна інтеграція, а CD (Continuous Delivery) — неперервна доставка. Цей набір методик дозволяє розробникам частіше і надійніше розгортати зміни в ПЗ.

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

Пояснимо суть CI/CD через чотири W:

What?

CI/CD — популярна DevOps-практика, яка автоматизує, систематизує та прискорює процес доставки змін в коді до кінцевого споживача. 

CI (Continuous Integration) — неперервна інтеграція.

CD (Continuous Delivery) — неперервна доставка.

Why?

Більшість IT-продуктів створюють із використанням різних платформ та інструментів. CI/CD забезпечує їх автоматизовану збірку, тестування та розгортання у програмному середовищі.

Як наслідок: 

• команда розвантажується; 
• розробники приділяють максимум часу якості коду / безпеці продукту.

Where?

Набір методик CI/CD використовується: 

• на великих проєктах;
• у продуктових розробках, що активно зростають (де стрімко збільшується кількість користувачів, коду та апдейтів)

When?

Усе почалося з DevOps: цей напрямок об’єднав розробку, тестування та залучення до роботи більшої кількості команд. Завдяки роботі девопсів вдалося скоротити час розробки, збільшити кількість коду та частоту релізів. 

Все це стало підґрунтям для розвитку CI/CD :)

Who?

Зазвичай CI/CD налаштовують та запускають DevOps-інженери. Вони пишуть код для автоматизації процесів. У невеликих командах функції DevOps можуть виконувати розробники. Тож перейти на світлу сторону CI/CD може кожен IT-експерт.

CI: з чого все починається

Безперервна інтеграція — ключовий елемент DevOps-підходу. Саме він сприяє злагодженій роботі команди та швидкому отриманню зворотного зв’язку. Учасники розробки публікують зміни якнайчастіше, щоб якомога раніше побачити фідбек. 

Відповідно до принципу CI, зміни відображаються в системі контролю версій. Наразі стандартом для більшості компаній є Git. Цей інструмент опенсорний, зручний та гнучкий. Та згадаємо й інші: Mercurial, Subversion або SVN (упокій його душу, страшне легасі), Concurrent Versions System, GNU Bazaar, BitKeeper.

Також є сервіси, що пропонують систему контролю версій як послугу. Вони можуть бути у вигляді selfhosted чи cloud. Основними гравцями на цьому ринку є Bitbucket, GitLab та GitHub.

Системи контролю дають можливість спільно працювати над одним початковим кодом. Вони зберігають історію змін та мають зручні інструменти для розгалуження, злиття та вирішення конфліктів, відстеження й обговорення коригувань. Також системи контролю версій передбачають версіонування, яке багато в чому є ключовим аспектом CI/CD. Про цю можливість далі поговоримо окремо.

У більшості випадків безперервна інтеграція передбачає список дій, що просувається. Він бере початок у системі контролю версій, але через велику кількість факторів може закінчитися будь-якої миті… Насправді ж межа між завершенням CI та початком CD досить розпливчаста, і кожен інтерпретує її по-різному.

Проте є перелік дій, що стосуються CI:

• детектування змін у системі контролю версій (наприклад, клонування репозиторію з нуля або стягування останніх змін);
• збірка коду та юніт-тести (це стосується мов, що компілюються);
• фідбек.

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

Одним із найпопулярніших інструментів тут є Jenkins. Часто згадують про TravisCI, CircleCI, Bamboo, TeamCity, а також GitLab CI та GitHub Actions як CI/CD extensions для цих SCM-платформ. Усі вони допомагають спростити та прискорити розробку. За рахунок стандартизації процесів та їх автоматизації девелопер може зосередитись на основній задачі — написанні якісного коду. Час на очікування merge day (дня злиття) із заливкою величезного пакету змін залишаться в минулому.

Вагому роль також відіграє фідбек. Що раніше буде виявлено проблему, тим дешевше коштуватиме її виправлення. А це оцінить будь-який бізнес.

Bad practices в CI

В інтернеті можна знайти кілька популярних документів із детальним описом bad practices для CI/CD-процесу. Деякі пункти є суперечливими, та багато з них слушні й корисні:

• Структура проєкту у репозиторії не відповідає принципу модульності.

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

• Використання взаємозамінних плагінів та інструментів.

Вони дублюють один одного і вимагають час на додаткові перевірки з однаковим результатом. Якщо використовуєте для статичного аналізу коду SonarQube, його можливостей більш ніж достатньо.

• Об’єднання різних завдань в один логічний stage у пайплайні.

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

• Ігнорування локальних збірок.

Пам’ятайте про людський фактор. Через невелику помилку або схожу проблему можна втратити багато особистого часу та часу CI-сервера.

• Відсутність повідомлень.

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

CD: зберігаємо, перевіряємо, доставляємо

Друга частина процесу — Continuous Delivery — передбачає такі кроки:

• Зберігання. Після компіляції або збірки коду ви отримуєте артефакт. Це широке поняття з безліччю варіацій: Maven-артефакти, Python-артефакти, NuGet-репозиторії з .NET, RubyGems, Docker Image та навіть ZIP-архіви з JS-файлами. Можна зберігати ці документи локально, але не варто. З комп’ютером чи розробником завжди щось може статися. В результаті команда не отримає артефакт. Тому зберігайте артефакти в окремих репозиторіях. Це підвищує безпеку та забезпечує гнучкі можливості: централізоване чи структуроване зберігання, версіонування тощо.
• Перевірка. Отриманий артефакт, як і в CI-частині, треба тестувати. Ви повинні зрозуміти, чи правильно він зібрався, чи відповідає вміст певним вимогам безпеки, політики та чистоти коду. Маються на увазі насамперед статичні аналізатори (динамічні стосуються робочого застосунку після деплою). Так ви впевнитесь, що не відправите в деплой щось неправильне.
• Деплой. Після вибору інструментів (із міркувань неповторності та перевірки артефактів на відповідність заданим профілям) можна деплоїти їх на робочі потужності. Варіантів реалізації багато. Це може бути локальний комп’ютер, Kubernetes-кластер, виділений сервер, хмара від AWS або Azure тощо. Вибір залежить від проєкту та вимог замовника.
• Моніторинг. Не можна йти за принципом «задеплоїв та забув». Ви повинні стежити за роботою програми. Налаштуйте систему моніторингу з надсиланням повідомлень, відстежуйте результати, аналізуйте метрики та алерти у разі збоїв. Це дозволить вам оперативно вирішувати проблеми з мінімальним простоєм програми.

Bad practices у CD

• Деплой локально зібраного артефакту.

Так робити не можна за жодних обставин. Ваша система збірки та деплою на локальній машині не є стандартизованою та загальною. Артефакт може відрізнятись від аналога в системі CI. Тому завжди використовуйте пайплайн для збірки та деплою.

• Сховище артефактів не використовується.

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

• Відсутність стратегії у разі поломки артефакту

Завжди щось може піти не за планом. На такий випадок продумайте чіткі процедури та покроковий план. Це дозволить відновити робочий стан вашого середовища.

• Невідповідність між початковим кодом та одержуваним артефактом

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