Пайплайн CI/CD: що це таке, як застосовується у розробці та bad practices

Продовжуємо тему CI/CD (Continuous Integration, Continuous Delivery): у попередній частині блогу ми розібралися, що це за технологія і як вона може зекономити робочий час розробнику. Тепер розкажемо про нюанси роботи з CI/CD-пайплайнами, погані практики, а також версіонування як спосіб менеджменту змін у коді.

Пайплайни

При об’єднанні CI та CD виходять пайплайни. Всі про них чули, але часто трактують це поняття по-різному. В одному проєкті пайплайном можуть назвати окрему фічу чи задачу. Це частково вірно. Та насправді пайплайн — це послідовність певних дій, поділених на логічні одиниці: збірка проєкту, тести, завантаження артефактів у сховище, деплой тощо.

Щоб уникнути непорозумінь, на старті проєкту або приєднуючись до нової команди погодьте з усіма залученими командами одне значення пайплайну. У вас можуть бути CI-пайплайни, CD-пайплайни або їх комбінації. Без остаточного визначення терміну ви гаятимете час на постійні уточнення. Хтось створить у Jira тікет із фразою «У мене не працює пайплайн». І тут у вас виникне питання: про проблеми зі збіркою чи деплоєм?

Навчати вас створювати пайплайни у цій статті не будемо, але базові моменти розглянемо. Насамперед визначте, хто, чим і як зайнятий. Потім зафіксуйте бажаний результат. Пайплайн повинен мати сенс. А головне — ним мають користуватися всі. Часто буває, що хтось створив хороший пайплайн, але всі роблять по-старому, як звикли. Обов’язково пояснюйте колегам користь від запровадження нових підходів. Адже CI/CD — це про постійну взаємодію з усіма членами команди.

Типовий сценарій застосування пайплайну

Розглянемо універсальну модель вирішення будь-якого завдання. Почнемо з отримання розробником таску — в Jira чи на мітингу. Далі він створює окремий бранч у системі контролю версій, пише код чи вносить виправлення, локально тестує, створює пул реквест і просить когось відрев’юїти результат. Потім залишається з’єднати цю гілку з основною, зібрати та задеплоїти на dev-оточення.

Припустимо, на все це ви витратили тиждень. 90-95% часу пішло на написання коду, а на супутні дії та деплой знадобилося, скажімо, 2 години. Це логічне співвідношення. Але якщо на виправлення мікробага потрібно 10 хвилин, а на збірку і деплой припала година, то в процесі є проблеми. Раптом доведеться виправляти по 10 мікробагів на день, і тоді весь час йтиме суто на збірку та деплой.

Ситуація має два вирішення:

• Посунути зміни в часі. Ви можете відтягувати момент злиття змін до основного бранча. Так ви збільшите кількість змін у пул реквесті, який створите згодом. Однак рев’юїти полотно коду замість пари рядків складно та ризиковано.
• Налаштувати CI/CD-пайплайн. Цей інструмент автоматично збирає проєкт, тестує та деплоїть на dev-оточення. Такий підхід економить час та скорочує ймовірність збоїв через людський чинник.

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

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

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

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

Bad practices у пайплайнах

• Пов’язані з пайплайном ресурси не версіонуються.

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

• Використання shell-скриптів.

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

• Неправильна послідовність пайплайн стейджів.
Онлайн-курс Бізнес-аналіз. Basic Level від Ithillel.
В ході курсу студенти навчаться техніці збору і аналізу вимог, документуванню та управлінню документацією, управлінню ризиками та змінами, а також навчаться моделювати процеси і прототипуванню.
Приєднатися

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

• Пропуск кроків у пайплайні.

Ланцюжок дій повинен виконуватися від початку до кінця. Іноді є спокуса пропустити якийсь етап. Наприклад, за крок тестів передбачено 1000 перевірок, але 1-2 з них проблемні, вони руйнують увесь пайплайн. Можна пропустити крок, але не варто. У такому випадку краще попросити QA-команду усунути збої чи видалити ті проблемні тести, А ті 998, що залишилися, нехай працюють далі.

• Запуск деяких пайплайнів вручну.

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

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

Неприпустимо у пайплайнах. Причини такі самі, як у CI- та CD-частинах.

• Невикористання параметризованих завдань.

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

• Відсутність неймінгу або невміння його робити.

Джоб- та пайплайнам варто підібрати найменування. Чому це важливо? У разі невдалого неймінгу на CI-сервері можуть виникати дублікати. Це особливо поширено на великих проєктах, де кілька команд займаються однаковими завданнями. Крім цього, невиразні назви ускладнюють пошук потрібних джобів. Вам доведеться витрачати час, аби визначити, що робить та чи інша джоба, чи це вам дійсно потрібно.

• Нестача тестів на продоподібному stage-оточенні.

Тут все просто: ви повинні переконатися в якості продукту до його деплою на продакшен.

• Запуск тестів на продакшені.

Можна щось протестувати вже на продакшені. Для цього існує особлива техніка: вибираєте кілька тестів, стартуєте їх — і хреститеся… Якщо опустити іронію, як ви могли зрозуміти, так робити не можна.

Версіонування як спосіб менеджменту змін у коді

Життєвий цикл програми так чи інакше пов’язаний з її версіями. Без згадування версії не зрозуміло, про який застосунок ідеться, який у нього функціонал, чи виправлені баги тощо. Також без версіонування є великий ризик отримати несумісність між окремими модулями або блоками, які використовуються в застосунку. Наприклад, під час переходу з версії 3.1 на 4.0 може перестати працювати основний функціонал. Стандартне версіонування передбачає певну сумісність продуктів.

Основна функція версій — навігація. Це можна порівняти з GPS-мітками тільки для коду.

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

Для версіонування можна використати:

• Числові версії.

Це найпоширеніший підхід. Він припускає кілька варіацій. Найпростіша — номери за порядком: 1, 2, 3… Також вони можуть мати дрібну частину: 1.1 або 2.5. Популярна трійкова система: з мажорною версією, мінорною та фікс-версією. Тоді остання цифра змінюється при фіксації багів без кардинальних змін у функціоналі. Середня цифра оновлюється з появою нових фіч та зворотної сумісності програми. Перша мажорна цифра коригується при великому апдейті чи несумісності з минулим релізом.

• Літерні версії.

Варіант позначення лише літерами латинського алфавіту не дуже поширений через обмеженість набору символів. Літери можуть використовуватися в трійковій системі для фікс-версії: 1.3.b, 4.2.c і т.п.

• Етапні версії.

Позначають етап процесу розробки продукту. Це можуть бути альфа- та бета-версії, реліз-кандидати, сервіс-релізи тощо.

• Календарні версії.
Курс Power Skills For Tech від Enlgish4IT.
Зменшіть кількість непорозумінь на робочому місці та станьте більш ефективним у спілкуванні в мультикультурній команді. Отримайте знижку 10% за промокодом ITCENG.
Реєстрація на курс

Проста і зрозуміла система — з універсальним порядковим елементом у вигляді дати, коли було запущено нову версію.

• Іменні версії.

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

Якщо вагаєтесь, яку концепцію для найменування версій обрати або взагалі не хочете витрачати на це час, радимо брати SemVer — семантичне версіонування. Цей стандарт створив співзасновник GitHub Том Престон-Вернер. SemVer поєднує послідовність чисел із трійковою системою. Дозволяє використовувати етапи складання або додаткові мітки на кшталт частин, хешів і комітів.

Потрапивши в діючий проєкт, вам залишається прийняти наявну систему версіонування. Єдине — переконайтеся, що концепція детально описана в Confluence або іншій wiki-системі проєкту. В документі має бути описано, як проводиться версіонування, як воно пов’язане з процесом розробки, як команда з ним взаємодіє, який наразі етап релізів тощо. Таким чином всі учасники розробки розумітимуть, що відбувається на проєкті.

Взаємодія з командами

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

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

До впровадження CI/CD колег варто готувати заздалегідь. Іноді для побудови пайплайну достатньо кількох хвилин і десяток кліків. Та зазвичай це більш тривалий процес. Тож поцікавтесь перебігом робіт та планами кожної команди. В іншому разі можуть виникнути серйозні труднощі з інтеграцією нових ідей до вже створеного пайплайну.

Зіставляйте зусилля та результати

Час — беззаперечно найцінніший ресурс, і CI/CD заощаджує його.

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

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