«Запустив білд. Пішов зварив каву. Повернувся. Ще крутиться».
Ось так виглядав звичайний день на enterprise-платформі e-commerce, куди мене покликали. Пайплайни на Jenkins були настільки повільними, що розробники міряли збірку не хвилинами, а походами по каву. А тепер помножте це на кожен pull request, кожну feature-гілку, кожен хотфікс — на всю інженерну команду. Виходить дуже дорога звичка, яку ніхто навіть не намагався порахувати. Мене взяли рівно за одним: повернути швидкість. Це чесна історія тієї самої міграції з Jenkins на GitHub Actions — що я знайшов, що реально змінив і що врешті спрацювало.
Легасі-біль за підручником
Все в цій конфігурації було з серії «киваєш, бо бачив це десять разів». Усе виконувалося послідовно. Кешування не було взагалі — кожен запуск пересобирався з нуля. Спільні раннери стояли в черзі по двадцять хвилин, перш ніж білд взагалі стартував. А зверху — шар flaky-тестів, які ніхто не чіпав: єдиним «фіксом» було перезапустити й сподіватися на зелений.
Ось це останнє важливіше, ніж звучить. Коли твій єдиний спосіб полагодити — «запусти ще раз», ти вже програв. Пайплайн перестає бути інфраструктурою й перетворюється на гральний автомат.
Я почав із карти, а не з міграції
Перш ніж написати бодай рядок нового YAML, я склав карту всіх пайплайнів, які реально працюють. Не за документацією — її не було. За живими, робочими джобами. Їх виявилося 47. Деякі не чіпали три роки, але вони справно запускалися щодня. Половину з них ніхто в офісі не міг навіть пояснити — що вони деплоять.
Саме цей крок усі пропускають, і саме він рятує. Не можна модернізувати те, чого не бачиш. Тож спершу я зафіксував реальну картину, а потім знайшов боттлнеки:
- Послідовний прогін тестів — без жодної причини, просто так історично склалося
- Повне встановлення залежностей на кожному запуску — нічого не кешувалося, кожен білд заново тягнув пів світу
- Нуль паралелізму між сервісами — усе чекало своєї черги
- Ручні approve-гейти — що впиралися в одну людину, яка вічно була на зустрічах
Що я повторював стейкхолдерам як мантру: проблема не в інструменті. Просто замінити Jenkins на GitHub Actions, зберігши ту саму форму, не дало б майже нічого. Міграція була приводом. Сенс був у зміні архітектури.
Нова архітектура
Замість моноліту з джоб-сніжинок я зібрав щось модульне й нудне — нудне в найкращому сенсі.
- Спільні перевикористовувані workflow — одне джерело правди, яке смикає будь-який репозиторій в організації, замість 47 різних варіантів руками
- Matrix builds — тести паралельно на кількох версіях Node, а не в одну повільну смугу
- Кеш залежностей — білд перестав платити повний «податок на встановлення» щоразу
- Аналітика білдів по кожному pull request — розробник нарешті бачив, чи сповільнив його коміт збірку
- Деплой із health-check-гейтами та автоматичним відкатом — більше жодних схрещених пальців на релізі
В основі всього лежав один універсальний шаблон пайплайна на 634 рядки. Тепер кожен сервіс деплоїться однаково. Жодних конфігів-сніжинок, жодного «ну в мене ж на моєму Jenkins працює». В enterprise-масштабі ця стандартизація вартує не менше, ніж сама швидкість.
Результат
Білди, що раніше йшли 55 хвилин, тепер завершуються за 7.
Це заголовкова цифра, і вона справжня. Але цифра, яка мені насправді дорога, — це зміна поведінки за нею. Розробники перестали варити каву під час збірки, бо білд закінчується раніше, ніж закипає чайник. Один із них сказав, що відчуття — ніби перейшов в іншу компанію. Ось це і є перемога — не сім хвилин, а те, що деплой перестав відчуватися як покарання.
Найскладніше було не технічним
Буду чесним. Паралельні білди, кеш, matrix-тести — це просто інженерія. Вона пізнавана й скінченна, її можна просто перемолоти. По-справжньому складним було переконати команди, що біль від зміни менший, ніж біль від того, щоб залишитися як є. Люди вже змирилися з походами по каву. Вони вибудували весь свій день навколо зламаного пайплайна. Зміна — це загроза рівно до того моменту, поки вона перестає нею бути.
Твій пайплайн — це продукт
Ось що я хочу, щоб ви звідси забрали. Повільний пайплайн — це не дрібна незручність, яку можна обійти. Це податок на кожного розробника, щодня. Він тихо вбиває темп, а потім вбиває мораль.
Ваш CI/CD-пайплайн — це продукт, а розробники — його користувачі. Вимірюйте його. Оптимізуйте. Ставтеся до 55-хвилинного білда як до інциденту, яким він і є. Зробіть це — і ви повернете людям те саме відчуття, заради якого вони взагалі пішли писати код: відчуття відвантаження.
Тож чесно: скільки зараз іде ваш найповільніший пайплайн — і ви, часом, просто мовчки з цим змирилися?