Що таке CI/CD?

Стаття також доступна російською (перейти до перегляду).

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

Традиційні підходи до розробки та випуску релізів

В ідеалізованому варіанті основними завданнями будь-якого робочого процесу розгалуженої розробки веб-додатку є:

• Можливість одночасної роботи усіх учасників робочого процесу;

• Відсутність конфліктів коду при внесенні змін;

• Швидке та безпомилкове злиття коду;

• Періодичне локальне та модульне тестування;

• Швидка доставка та розгортання коду у виробничому середовищі без втрат надійності.

Для вирішення вказаних завдань більшість команд розробників під час робочого процесу використовують один або декілька репозиторіїв коду, інтегрованих із системою контролю версій – Git або її різновидами, котрі включаютьAPI для інтеграції та інтерфейс командної строчки для управління більш складними процедурами.      

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

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

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

Застосування CI/CD-конвеєрів для автоматизації робочого процесу

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

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

Вказана методика отримала назву процесу безперервної інтеграції CI(Continuous Integration) коду. Однак, процес не був би довершеним та повним без наявності підготовлених ізольованих середовищ для виконання незалежних тестувань, збірки та інших операцій по підготовці та випуску релізів. Такі середовища можуть бути реалізовані на базі систем управління контейнерними середовищами – Docker або Kubernetes. За їх налаштування та підготовку до розгортання коду відповідає процес CD (Continuous Delivery) безперервного постачання або розгортання (Deployment) коду. 

Об’єднання вказаних механізмів дає змогу отримати єдиний керований pipeline конвеєр для організації автоматизованого робочого процесу розробки веб-додатків. Зазвичай, він позначається як CI/CD. 

Тепер ми можемо сформулювати основні принципи або умови організації DevOps процесу для масштабних веб-проектів:

• Репозиторій на базі системи контролю версій;

• Підготовлений конвеєр CI/CD безперервної інтеграції та постачання коду;

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

• Ізольоване середовище виконання на базі стандартизованих контейнерних технологій;

• Робота із інфраструктурою проекту за принципами IAC;

• Моніторинг роботи CI/CD-конвеєру та контроль запущених процесів;

• Використання виділеного VPS або іншого серверу для запуску головного процесу проекту.    

Дотримання вказаних умов є показником застосування сучасного підходу до організації робочого процесу для масштабних проектів.  

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

Існує чимало програмних платформ, здатних забезпечити необхідні умови для організації робочого процесу розробки веб-додатків у вигляді автоматизованого CI/CD-конвеєру. Усі вони мають власну технологічну базу, різну ступінь відкритості, але все одно спираються на зазначені нами принципи організації DevOps процесу. Найбільш відомі з них: GitHub, Jenkins, Azure DevOps та GitLab. 

Виділимо загальні характеристики для більшості існуючих платформ із можливостями CI/CD:

• Мають власні віртуальні середовища та runner-сервери для запуску workflow-процесів;

• Етапи виконання кожного процесу визначаються за допомогою YAML-файлу, зареєстрованого у репозиторії компанії-розробника;

• Запуск процесів ініціюється за допомогою events-подій, котрі можуть викликатися різними шляхами – самою платформою, за розкладом через REST API або вручну;

• YAML-файл містить набір завдань, кожне з яких виконується у окремому виконавчому середовищі за визначеним сценарієм;

• Мають влаштовані засоби планування, моніторингу та управління workflow-процесом.

Нижче наведений приклад YAML-файлу для механізму GitHub Actions однойменної платформи, котрий реалізує можливості CI/CD:

jobs:
  build_1:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Це завдання запуститься першим"
 
  build_2:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Це завдання запуститься разом із build_1"
 
  testing_12:
    runs-on: ubuntu-latest
    needs: [build_1,build_2]
    steps:
      - run: echo "Це завдання буде запущене після виконання двох попередніх"
 
  deploy_12:
    runs-on: ubuntu-latest
    needs: [testing_12]
    steps:
      - run: echo "Це завдання буде запущене лише після завершення виконання testing_12"

Наведений сценарій реалізує робочий процес, котрий розпочинається із запуску та паралельного виконання двох завдань – build_1таbuild_2. Після їх завершення почне виконуватися завдання із ім’ям testing_12, і лише після нього запуститься завдання deploy_12. Таким чином сценарій демонструє варіант запуску взаємозалежних завдань, що у коді  позначається за допомогою команди needs.