CI/CD — методологія розробки, яка передбачає безперервну інтеграцію (CI) та безперервну доставку (CD) програмного коду. Її суть полягає в тому, що збірка та тестування відбуваються в автоматичному режимі. Навколо цієї поширеної DevOps-практики виникло чимало міфів та упереджень. Це складний затратний метод, який підходить лише для великих інноваційних продуктів? Чи ці принципи можуть застосовувати навіть найпростіші проєкти, на кшталт сайтів-лендингів? Запровадження CI/CD передбачає 100% автоматизований пайплайн чи без ручних перевірок не обійтися? Налаштування за принципом IaC — мастхев чи можна все зробити через інтерфейс? У цьому матеріалі Ілля Ільїн, DevOps Engineer в Jiji, партнерській компанії Genesis, спростовує найпоширеніші міфи про CI/CD.
МІФ №1
CI/CD — занадто складно і затратно, простіше зробити «руками»
Впровадження та налаштування процесів CI/CD може здаватися складним та затратним, нібито вимагати чималих ресурсів, зокрема якщо передбачається використання платних послуг та інструментів. Іноді на автоматизацію якогось процесу, який займає годину-дві щодня, може піти кілька місяців. Чи раціонально інвестувати в це час та ресурс, коли ручні методи виглядають простішими та економнішими?
Такі упередження виникають у розробників із недостатнім досвідом в інструментах і процесах автоматизації. Насправді CI/CD має безліч переваг: допомагає зменшити ризики та помилки, прискорити реліз, автоматизувати рутинні процеси, щоби команда могла зосередитись на розробці функціонала.
Уявімо, що є сайт, на якому під час реєстрації користувач вказує номер телефона, на який приходить код. Розробники припустилися помилки, залишивши у відкритому доступі реквест до API відправки СМС. Тобто можна відкрити консоль браузера, взяти цей реквест, скопіювати і почати відправляти СМС у великій кількості. Так за кілька годин можна легко «злити» бюджет у кілька тисяч доларів. Для порівняння: річна вартість утримання інфраструктури, яка могла б перешкоджати подібним помилкам — близько $1000. Тому витрати на CI/CD лише умовно можна назвати дорогими. Економія на інфраструктурі може спричинити значно більші втрати.
МІФ №2
CI/CD підходить не всім проєктам
Насправді ж процеси CI/CD можна легко масштабувати для проєктів будь-якого розміру. Зокрема, кожна команда має працювати через систему контролю версій — від студентських практичних завдань до великих глобальних продуктів.
Навіть прості лендинги зі зростанням проєкту стикаються з потребою в автоматизації. Наприклад, є звичайний статичний сайт на декілька сторінок і з кнопкою «Подзвоніть нам». Ніякої автоматизації, тестування, системи контролю версій немає. Розробник просто заходить на сайт через SSH або FTP, і кидає статичну сторінку на сервер. Якщо трапляються помилки — виправляє їх вручну. Але щойно відвідуваність сайту починає зростати, до його роботи треба ставитися прискіпливіше — додавати контур тестування, щоби було менше помилок, або покращувати безпеку чи конфіденційність. Найпростіший варіант це зробити — обмежити доступ розробників до прода. А для цього треба налаштовувати автоматичне завантаження коду. А якщо ти розумієш, як це працює, то в принципі це налаштовується доволі швидко і просто.
МІФ №3
Кінцева точка СІ — це реліз
Реліз продукту часом помилково сприймають як основну мету та кінцеву точку. Це свідчить про неправильне розуміння суті CI/CD, адже це циклічні безперервні процеси, у яких немає кінцевої точки. CI/CD містить такі етапи:
автоматична збірка та компіляція коду при кожному коміті в репозиторій;
запуск тестів після кожної збірки;
розгортання оновленого програмного забезпечення на тестові та стейджингові середовища для перевірки;
реліз;
постійний моніторинг для виявлення проблем.
Отже, постійне тестування й оновлення коду продовжується навіть у проєктах, розвиток яких призупинений — просто вони оновлюються не фічами, а виправленнями багів. Кінцевою точкою проєкту може бути тільки його повне закриття.
МІФ №4
Якщо конвеєр не автоматизовано повністю, і в ньому є «ручні» кроки, — це не CI/CD
Якщо розробнику під час релізу треба заходити на сервер по SSH, щось вмикати/вимикати, копіювати код вручну — це не про CI/CD. Проте натиснути на кнопку, щоби запустити скрипт або перевірити, чи немає помилок при деплої — цілком відповідає принципам CI/CD.
Деякі процеси не можуть бути автоматизованими на 100%. Наприклад, коли при релізі треба додати зміни до структури бази даних, ви не зможете автоматично протестувати, чи не виникло блокування патчів. Найпростіше — перевірити локи у напівручному режимі. Девопс-інженер може одразу пофіксити їх з допомогою спеціальних інструментів або звернути увагу розробника на цю проблему.
Іноді повна автоматизація, зокрема релізного бранчу, може спричинити падіння проєкту та великі втрати. Саме так 2021 року впала соціальна мережа Facebook. До інциденту команда хизувалася автоматичним тестуванням мережевих правил, маршрутизації, трафіку — все це автоматично накатувалося на прод без ручної перевірки. Під час інциденту 2019 року, який тривав вісім годин, у них впало все — внутрішня мережа, зовнішня мережа, канал комунікації між менеджерами, який був у їхньому месенджері, резервний канал спілкування у Slack, авторизація в якому проходила через акаунт Facebook. Також впала авторизація входів в дата-центри, які працювали через Facebook-ID, тому в деяких місцях їх відкривали фізично. Також це падіння вплинуло на чимало процесів користувачів та бізнесів — SDK, API, статистики тощо. Аналіз інциденту в post mortem свідчить, що це сталося через помилку, яку можна було б легко помітити, якби система не була на 100% автоматизована.
МІФ №5
CI/CD краще налаштувати через вебінтерфейс
Налаштування CI/CD-процесу через інтерфейс (наприклад, Jenkins чи TeamCity) здається більш простим, зрозумілим та зручним підходом, ніж використання конфігураційних файлів (наприклад, YAML). Вважається, що налаштування «кодом» потрібно лише для складних спеціалізованих потреб розробки.
Водночас, коли вся інфраструктура керується за принципом IaC (Infrastructure as Code), розробникам фактично можна не вести документацію. Хто б не прийшов до проєкту, він зможе просто відкрити репозиторій, подивитися код, побачити всю історію змін і все зрозуміти.
Подбати про правильний спосіб налаштування потрібно якомога раніше — коли проєкту 5-10-15 років, і весь цей час його налаштовували через юзер-інтерфейс, перейти на IaC буде доволі складно й дорого.
МІФ №6
Пайплайни CI/CD негнучкі, важко вносити в них зміни
Налаштований пайплайн CI/CD часом сприймають як непроникний процес, будь-які зміни та оновлення якого є складними та ризикованими. Насправді ж пайплайни мають бути гнучкими та адаптивними, щоби команди могли їх легко змінювати, відповідно до нових вимог та потреб.
Здатність CI/CD-пайплайну до змін передусім залежить від складності узгодження цих самих змін, розміру проєкту та ступеня забюрократизованості сфери. Наприклад, якщо це маленький стартап, DevOps і розробник можуть просто домовитися протестувати певний сервіс, одразу реалізувати, і цього ж дня він буде на проді. У фінансово-банківській сфері будь-які зміни мають бути узгоджені з сек'юріті-відділом або з регуляторами. Є банки, де перед тим, як відправити код на прод, треба його роздрукувати та поставити мокру печатку відповідальної особи.
До речі, з початком повномасштабної війни більшість українських банків перевели ключові операції до хмарної інфраструктури, щоби менше залежати від апаратного забезпечення в локальних дата-центрах. Вони зробили це у досить швидкі терміни, не зупиняючи поточну роботу. Найшвидше з цим впорався monobank, переїхавши в AWS за кілька тижнів. Для цієї сфери такий термін можна вважати миттєвим.
