Що таке CI/CD? Безперервна інтеграція і доставка простими словами
CI/CD — це спосіб випуску програмного забезпечення, за якого кожна зміна коду автоматично збирається, тестується і, якщо проходить перевірку, готується до випуску або випускається. CI (безперервна інтеграція) означає, що зміни часто зливаються і щоразу перевіряються автоматичними тестами. CD (безперервна доставка або розгортання) означає, що зміни, які пройшли перевірку, пакуються і спрямовуються до користувачів із мінімальною або нульовою ручною роботою.
Суть проста: ловити помилки за хвилини після їх появи, а не через тижні, коли клієнт їх виявить.
Чому CI/CD важливий, коли ви створюєте з ШІ
ШІ-конструктори вносять зміни в код швидко. Один промпт може торкнутися десяти файлів. Ця швидкість чудова, доки зміна на сторінці оформлення замовлення тихо не зламає сторінку входу, і ніхто цього не помітить, поки користувач не напише вам листа.
CI/CD — це страхувальна сітка саме для таких ситуацій. Замість того щоб довіряти, що кожна зміна в порядку, конвеєр запускає ті самі перевірки щоразу:
- Чи досі застосунок збирається без помилок?
- Чи досі проходять автоматичні тести?
- Чи дотримується код правил проєкту (типи, форматування, перевірки безпеки)?
Якщо якась перевірка не проходить, зміну зупиняють до того, як вона дійде до користувачів. Чим швидше змінюється ваш код, тим цінніша перевірка, яка не втомлюється і не пропускає кроків.
Повсякденна аналогія
Уявіть пекарню, яка щоранку постачає хліб магазинам.
- Без CI/CD кожен пекар тиждень вносить власні зміни в рецепти, а потім у п'ятницю ввечері всі їх поєднують і сподіваються, що хліб усе ще підійде. Коли не підходить, ніхто не знає, чия зміна до цього призвела.
- З CI кожна дрібна зміна рецепта одразу випікається як пробна паляниця і перевіряється — смак, вага, форма. Погана зміна виявляється того самого дня, і ви точно знаєте, яка саме це була.
- З CD буханці, які пройшли перевірку, одразу йдуть у фургон доставки, упаковані й промарковані однаково щоразу, а не пакуються вручну о п'ятій ранку.
Перевірка не робить пекарів кращими. Вона робить їхні помилки дешевими.
Як працює конвеєр CI/CD
Конвеєр — це список кроків, які сервіс CI/CD виконує автоматично, коли щось трапляється, зазвичай коли хтось надсилає код до репозиторію на кшталт GitHub. Типовий конвеєр виглядає так:
| Крок | Що відбувається | Що ловить |
|---|---|---|
| 1. Запуск | Код надіслано або відкрито pull request | — |
| 2. Встановлення | Нова машина завантажує код і його залежності | Відсутні або зламані пакети |
| 3. Збірка | Застосунок компілюється або пакується | Синтаксичні та типові помилки, зламані імпорти |
| 4. Тестування | Запускаються автоматичні тести | Функції, які більше не працюють |
| 5. Перевірки | Лінтинг, форматування, сканування безпеки | Проблеми стилю, відомі вразливі пакети, витеклі ключі |
| 6. Розгортання в staging | Застосунок переходить до тестової копії продакшену | Проблеми, які проявляються лише в реальному середовищі |
| 7. Розгортання в продакшен | Застосунок виходить у роботу — автоматично або після затвердження | — |
Кожен крок виконується на чистій машині, а не на чиємусь ноутбуці, тож виправдання «у мене на комп'ютері працює» більше не спрацьовує. Якщо крок не вдався, конвеєр зупиняється і повідомляє тому, хто вніс зміну.
Кроки визначено у файлі конфігурації, який лежить разом з кодом. У GitHub Actions, наприклад, це YAML-файл у папці .github/workflows репозиторію.
Безперервна доставка проти безперервного розгортання
«CD» неоднозначне, і люди вживають його по-різному:
| Безперервна доставка | Безперервне розгортання | |
|---|---|---|
| Тести запускаються автоматично | Так | Так |
| Випуск автоматично пакується | Так | Так |
| Виходить у роботу автоматично | Ні — людина натискає «випустити» | Так — кожна зміна, що пройшла перевірку, виходить у роботу |
| Добре підходить для | Більшості невеликих команд, застосунків з платними користувачами | Команд із хорошим покриттям тестами та моніторингом |
Безперервне розгортання працює добре лише тоді, коли тести якісні. Якщо ваші тести не покривають оформлення замовлення, безперервне розгортання із задоволенням виведе в роботу зламане оформлення.
Практичний приклад: застосунок бронювання з конвеєром
Припустимо, у вас є застосунок для бронювання в салоні краси, а його код лежить у репозиторії GitHub. Ви просите ШІ-конструктор: «Додай 10% знижку для клієнтів, які вперше приходять».
- Зміну надсилають у нову гілку і відкривають pull request.
- Запускається конвеєр. Він встановлює пакети і збирає застосунок — успішно.
- Він запускає тести. Один тест, «клієнт, який повертається, платить повну ціну», провалюється: знижка застосовується всім.
- У pull request з'являється червоний хрестик. Зміну не можна злити.
- Ви просите ШІ виправити. Він надсилає виправлення; конвеєр запускається знову, і все проходить.
- Зміну зливають. Конвеєр розгортає її в staging-середовищі, де ви робите тестове бронювання.
- Ви затверджуєте — і зміна розгортається в продакшені.
Без конвеєра крок 3 відбувся б із грошима ваших клієнтів.
Ключові терміни
| Термін | Значення |
|---|---|
| Конвеєр (pipeline) | Автоматична послідовність кроків, яка виконується для кожної зміни. |
| Збірка (build) | Перетворення вихідного коду на щось, що може працювати. |
| Автоматичний тест | Код, який перевіряє, що інший код робить те, що має. |
| Pull request (PR) | Запропонована зміна, яку переглядають інші (і конвеєр), перш ніж злити. Див. що таке GitHub. |
| Гілка (branch) | Окрема лінія змін, щоб робота в процесі не впливала на основний код. |
| Staging | Приватна копія вашого застосунку, що дублює продакшен, для перевірки змін перш ніж користувачі їх побачать. |
| Продакшен (production) | Жива версія застосунку, якою користуються ваші клієнти. |
| Відкат (rollback) | Повернення до попередньої робочої версії, коли випуск пішов не так. |
| Зелена / червона збірка | Запуск конвеєра, який пройшов успішно / провалився. |
Поширені хибні уявлення
- «CI/CD означає, що мій застосунок протестовано». Конвеєр запускає лише ті тести, які у вас є. Якщо тестів немає, CI лише доводить, що застосунок збирається — і більше нічого. Попросіть ШІ написати тести для найважливіших сценаріїв.
- «CI/CD — лише для великих компаній». Хостингові інструменти на кшталт GitHub Actions налаштовуються коротким файлом конфігурації, і малі команди користуються ними постійно. Зусиль потребують тести, а не інструменти.
- «Автоматичне розгортання означає, що ніхто нічого не перевіряє». Хороші конвеєри додають перевірки, а не прибирають їх. Багато команд зберігають крок ручного затвердження перед продакшеном.
- «Якщо конвеєр зелений, застосунок працює». Це означає лише, що автоматичні перевірки пройшли. Зміну все одно варто перевірити самостійно, краще в попередній версії або на staging.
- «CI/CD замінює резервні копії». Ні. Погана міграція бази даних, яка проходить тести, однаково може пошкодити реальні дані. Зберігайте резервні копії та спосіб відкату.
Що просити у вашого ШІ-конструктора
- «Напиши автоматичні тести для реєстрації, входу і оформлення замовлення і покажи, як їх запускати».
- «Налаштуй робочий процес GitHub Actions, який встановлює залежності, збирає застосунок і запускає тести для кожного pull request».
- «Додай перевірку типів і лінтер до конвеєра і зроби так, щоб він падав на помилках».
- «Простою мовою поясни, що робить кожен крок конвеєра».
- «Що станеться, якщо розгортання зламається на півдорозі? Як відкотитися?»
- «Перевір, що секрети не записані жорстко в репозиторії і не виводяться в журналах конвеєра».
Якщо ваш застосунок використовує API-ключі, конвеєру вони також потрібні — зберігати їх слід як зашифровані секрети в інструменті CI, а не у файлі конфігурації. Див. змінні середовища і секрети.
CI/CD і Mythex
Mythex не запускає для вас CI-конвеєр, але покриває кілька тих самих потреб по-своєму:
- Чекпоінти. Після кожного успішного ходу агента Mythex зберігає git-чекпоінт, а Повернутися до цієї точки відкочує проєкт, якщо зміна пішла не так. Див. Чат.
- App Testing. Введіть
/test, і агент пройде вашим живим прев'ю як користувач і повідомить про зламані сценарії — корисно перед кожною публікацією. Див. App Testing. - Публікація — свідомий крок. Зміни спочатку з'являються в приватному прев'ю; ваш публічний застосунок оновлюється лише тоді, коли ви публікуєте знову — ближче до безперервної доставки, ніж до безперервного розгортання.
- Синхронізація з GitHub (Pro). Синхронізуйте проєкт із репозиторієм GitHub, і ви зможете додати власні робочі процеси GitHub Actions, які запускають тести на кожен push. Див. GitHub і експорт.
Список того, що перевірити вручну перед запуском, див. у як протестувати застосунок перед запуском, а щодо роботи з системою контролю версій — як використовувати Git із застосунком, створеним за допомогою ШІ.
Запитання
Що означає CI/CD?
CI — це безперервна інтеграція: кожна зміна коду часто зливається з основним кодом і автоматично збирається та тестується. CD — це безперервна доставка або безперервне розгортання: зміни, що пройшли тести, автоматично готуються до випуску (доставка) або випускаються для користувачів без ручного кроку (розгортання).
У чому різниця між безперервною доставкою і безперервним розгортанням?
За безперервної доставки кожна зміна, що пройшла конвеєр, готова до випуску, але людина все одно вирішує, коли запустити її в роботу. За безперервного розгортання кожна зміна, що пройшла перевірку, виходить у роботу автоматично, без кроку затвердження людиною.
Чи потрібен CI/CD для невеликого застосунку, створеного з ШІ?
Не в перший день. Невеликий застосунок з кількома користувачами може обійтися тестуванням у попередній версії та публікацією вручну. CI/CD стає корисним, коли над кодом працює кілька людей, коли від застосунку залежать реальні клієнти або коли ви постійно ламаєте те, що раніше працювало.
Які інструменти використовують для CI/CD?
Поширені варіанти: GitHub Actions, GitLab CI/CD, CircleCI і Jenkins, а також вбудовані конвеєри розгортання хостингових платформ. Усі вони виконують одне базове завдання: автоматично запускають список кроків щоразу, коли змінюється код.