Як це працює на практиці
Уявімо, що розробник виправив помилку в кошику інтернет-магазину. Без автоматизації він вручну переносить файли на сервер і сподівається, що нічого не зламав. З налаштованим конвеєром усе відбувається інакше:
- розробник надсилає зміну в репозиторій Git;
- система автоматично запускає перевірки й тести;
- якщо все гаразд, зміна потрапляє на тестовий сервер, де її можна подивитися;
- після схвалення зміна виходить на робочий сайт, за правильного налаштування — без перерви для відвідувачів;
- якщо щось пішло не так, попередню версію повертають однією дією.
Абревіатура тут проста. CI — безперервна інтеграція, тобто постійна автоматична перевірка змін. CD — безперервна доставка, тобто автоматична викладка перевірених змін.
Що це дає бізнесу
- Менше збоїв після оновлень. Помилки ловляться на етапі перевірок, а не покупцями на робочому сайті.
- Частіші й менші оновлення. Нові функції виходять, щойно готові, а не накопичуються для великої ризикованої викладки.
- Незалежність від однієї людини. Викладка не залежить від того, чи у відпустці розробник, який «знає, як це робиться».
- Зрозуміла історія змін. Завжди видно, що, коли і ким було викладено, і до якої версії повернутися.
- Простіше підключати нових людей. Новий розробник запускає проєкт локально за кілька команд, а не збирає середовище вручну.
Навіщо потрібні контейнери
Контейнер — це «коробка», в якій лежить застосунок разом з потрібною версією мови, бібліотеками й налаштуваннями. Docker дозволяє запускати таку коробку на будь-якому сервері однаково. Це прибирає цілий клас проблем, коли на тестовому сервері все працювало, а на робочому — ні через іншу версію PHP чи відсутню бібліотеку.
Контейнери також спрощують переїзд між серверами й хмарними провайдерами та дозволяють запускати кілька копій застосунку, коли зростає навантаження. Для великих систем з багатьма контейнерами використовують Kubernetes, але для більшості проєктів він надмірний.
Є й зворотний бік. Контейнери додають ще один шар, який потрібно розуміти й обслуговувати: стежити за оновленнями базових образів, місцем на диску, журналами. Тому ми не переносимо в контейнери все підряд, а починаємо з тих частин, де різниця середовищ уже створює проблеми, і пояснюємо команді, як із цим працювати.
Кому це потрібно, а кому — поки ні
Автоматизація окупається, коли над проєктом працює кілька розробників, оновлення виходять часто, а ціна помилки на робочому сайті висока: інтернет-магазини, онлайн-сервіси, портали, мобільні застосунки з власним сервером.
Для невеликого корпоративного сайту, який оновлюється кілька разів на рік, складний конвеєр не потрібен. Але навіть тут варто мати код у Git і просту автоматичну викладку: це недорого і рятує від випадкових помилок.
Окремий випадок — коли розробку веде кілька підрядників або частину робіт виконує ваша власна команда. Спільні правила викладки тоді особливо корисні: кожен бачить, що змінили інші, а суперечки «хто зламав сайт» вирішуються за історією змін.
Варіанти: від простого до повного
- Проста автоматична викладка. Код з репозиторію сам потрапляє на сервер після схвалення. Найменше зусиль, вже прибирає ручне копіювання файлів.
- Конвеєр з перевірками й тестовим сервером. Додаються автоматичні тести та окреме середовище для перевірки. Оптимальний варіант для більшості комерційних проєктів.
- Повна контейнеризація. Усі частини проєкту працюють у контейнерах, інфраструктура описана кодом, наприклад через Terraform чи Ansible. Дає найбільше гнучкості, але потребує більше часу на налаштування й досвіду для обслуговування.
Що підготувати з вашого боку
- доступ до репозиторію з кодом або сам код, якщо він поки не в Git;
- доступи до серверів чи хмарного облікового запису, де працює проєкт;
- інформацію про те, хто зараз розробляє і викладає зміни;
- список зовнішніх сервісів і ключів доступу, які використовує застосунок.
Типові помилки при впровадженні
- Тримати паролі й ключі доступу просто в коді репозиторію.
- Намагатися одразу побудувати «ідеальний» конвеєр з Kubernetes для невеликого сайту.
- Налаштувати автоматичну викладку без можливості відкату.
- Мати тестовий сервер, який настільки відрізняється від робочого, що перевірка на ньому нічого не доводить.
- Забути про міграції бази даних: код оновився, а структура таблиць залишилась старою.
Як зрозуміти, що автоматизація працює
Результат видно не в налаштуваннях, а в повсякденній роботі. Через деякий час після впровадження варто подивитися на кілька речей:
- як часто після оновлень доводиться терміново щось виправляти на робочому сайті;
- скільки часу минає від готової зміни до її появи на сайті;
- чи може викласти оновлення будь-хто з команди, а не лише одна людина;
- скільки часу займає повернення попередньої версії, якщо щось пішло не так.
Якщо ці показники не покращуються, ми розбираємося, де конвеєр заважає, а не допомагає, і змінюємо його.
Що впливає на вартість
- Стан проєкту: чи є код у Git, чи є тести, наскільки складно запустити проєкт з нуля.
- Кількість частин: один сайт чи кілька сервісів, фонові обробники, мобільний застосунок.
- Кількість середовищ: лише робочий сервер чи також тестові й демонстраційні копії.
- Глибина автоматизації: проста викладка, конвеєр з перевірками або повна контейнеризація з описом інфраструктури кодом.
Часті запитання
Чи доведеться зупиняти розробку на час впровадження? Ні. Налаштовуємо конвеєр паралельно з поточною роботою і перемикаємо команду, коли він перевірений.
Чи можна впровадити CI/CD у старий проєкт? Так, хоча іноді спершу потрібно навести порядок у коді та залежностях. Для дуже застарілих систем це зазвичай частина поступової модернізації.
Чи потрібна хмара для контейнерів? Ні. Docker-контейнери чудово працюють і на звичайному орендованому сервері. Хмара корисна, коли потрібно швидко додавати ресурси, — про це на сторінці хмарної інфраструктури.
Чи потрібно одразу писати автоматичні тести? Не обов’язково. Конвеєр корисний і без них: він прибирає ручну викладку і дає швидкий відкат. Тести додаємо поступово, починаючи з найдорожчих для бізнесу сценаріїв — оформлення замовлення, оплати, реєстрації.
Хто підтримуватиме конвеєр після налаштування? Ваша команда за нашою інструкцією або ми в межах технічної підтримки.
Чому Promodex
Ми самі розробляємо сайти й застосунки з 2015 року, запустили 750+ проєктів і тому налаштовуємо автоматизацію з погляду команди, яка потім із нею працюватиме. Усе робить власна команда в Києві, без аутсорсу. У результаті ви отримуєте процес викладки, який розуміє вся команда, а не лише одна людина, і прозорий опис того, що й навіщо налаштовано.
