Що таке CI/CD, як він працює та коли знадобиться на проєкті. Лайфхаки та bad practices

Тема CI/CD включає багато технологій зі сфери DevOps і охопити їх всі в одній статті неможливо, тож вважайте, що це така собі «оглядова екскурсія». У цьому блозі ви дізнаєтесь, як впровадити цей процес у своїй команді та застосовувати CI/CD на практиці, а також опишемо bad practices.

Що таке CI/CD

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

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

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

• What?

Усе почалося з DevOps. На початку 2000-х цей напрям об’єднав розробку і тестування та залучення до роботи більшої кількості команд. Девопси стали поширювати принципи Agilе на розробку. Фахівці прагнули ще більше скоротити час розробки, отримувати якісніший код та збільшити кількість релізів. Це стало основою CI/CD. Тут зберігається фокус і на інструментах, і на взаємодії в команді. 

• Why?

CI/CD необхідний для автоматизації рутинних задач. Серед них — збірка та перетворення початкового коду на артефакт, відправка його на сервер, перевірка тестами тощо. Що більшим стає проєкт, тим частіше до коду вносяться зміни. Донесення користувачеві забирає чимало часу. А впровадження CI/CD заощаджує цей ресурс.

• Where?

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

• Who?

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

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. Тому завжди використовуйте пайплайн для збірки та деплою.

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

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

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

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

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

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

У продовженні блогу ми розповімо про пайплайни та версіонування — читайте на Highload незабаром.