Q&A по CI/CD

Continuous Integration (безперервна інтеграція) – практика інтеграції змін коду з гілки розробки в основну гілку шляхом інструментів для інтеграції.

Continuous Delivery (безперервна доставка) – практика утримання коду в репозиторії в стані придатному для розгортання на робоче оточення.

Continuous Deployment (безперервне розгортання) – практика доставки кожної зміни в коді продукту на робоче оточення.


Різниця між Continuous Delivery та Continuous Deployment дуже маленька. Уявімо два пайплайни для одного і того ж додатку. В кожному є кроки:

• Source Control – внесення змін в систему контролю версій ПЗ.
• Build – збірка додатку та прогін unit тестів
• Staging – деплой на тестове оточення, прогін інтеграційних, навантажувальних та інших тестів
• Production – деплой на оточення з користувачами

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

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

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

extends використовується для повторного використання секції пайплайна (аналог функції). .plan вказує на ім’я повторюваної секції в пайплайні. Першим в кроці виконується скрипт з extends.

Необхідно додати when: manual в опис заданої джоби. За замовчуванням при використанні when: manual параметр allow_failure встановлений в true, тому дана джоба буде запускатися автоматично. Щоб такого не було необхідно також встановити параметр allow_failure: false.