EVERYTHING
Як повідомляє Devops, більшість зусиль, спрямованих на виправлення нестабільності CI/CD — налагодження «flaky» пайплайнів, дослідження інтермітентних збоїв чи оптимізація порогових значень сповіщень — є цілком виправданими. Проте фундаментальні рішення, які визначають надійність конвеєра, були прийняті місяці або роки тому під час вибору інструментарію. До моменту початку дебагінгу команди часто стикаються з наслідками попередніх рішень, які здавалися раціональними в той момент.
Проблема поверхні інтеграції
Кожен інструмент у стеку розробки створює певну «поверхню інтеграції». Це сукупність зв'язків, які інструмент має з іншими елементами пайплайну: як він передає дані, ініціює дії, звітує про результати та обробляє помилки. Помилка полягає у тому, що інструменти завжди оцінюються ізольовано від контексту їхньої взаємодії. Наприклад, тестовий інструмент може мати чудову автономну продуктивність, але його вихідний формат не читається жодним іншим елементом пайплайну нативно. Аналогічно, деплоймент-інструмент із потужними функціями може потребувати власного скриптингу для підключення до платформи моніторингу.
Кожна така кастомна взаємодія є точкою вразливості. А кожна точка вразливості — це потенційний збій пайплайну, який не має жодного відношення до самого коду. Команди зі стабільними CI/CD мають спільну рису: вони оцінюють поверхню інтеграції так само серйозно, як і функціонал інструментів. Вони обирають ті засоби, які чисто комбінуються з рештою системи, а не обов'язково найбільш потужні в окремій категорії.
Вплив вибору тестових інструментів на пайплайн
Серед усіх елементів стеку, тестові інструменти мають найпряміший і недооцінений вплив на надійність CI/CD. Причина не лише швидкість виконання тестів, хоча вона також важлива. Головна проблема — це те, як тестові засоби вирішують питання залежностей. Кожен автоматизований тест, який звертається до зовнішнього сервісу, бази даних чи API нижчого рівня, повинен визначити, як репрезентувати цю залежність під час виконання.
Відповідь на це питання — чи передбачає вона використання живих залежностей, контейнеризованих реплік, вручну написаних мозків чи записаних взаємодій — визначає, наскільки стабільно поводиться тестовий набір у різних середовищах пайплайну. Тестові засоби, які повністю залишають питання залежностей розробникам, створюють невідповідні результати між різними середовищами. Той самий тест може пройти локально, але провалитися в CI або пройти в staging з причин, не пов'язаних із кодом.
Кожна необґрунтована розбіжність підриває довіру до пайплайну. Коли команди перестають вірити результатам конвеєра, вони додають ручні кроки верифікації. Ручна перевірка сповільнює доставку продукту. А повільна доставка створює тиск на обхід тестів. Проблема надійності посилюється через рішення щодо тестового інструменту, прийняте на початку проєкту. Інструменти, які мають принциповий підхід до обробки залежностей — що працює послідовно у локальному, CI та staging середовищах — створюють пайплайни, яким довіряють інженери. Довірені пайплайни використовуються належним чином і виявляють регресії ще до запуску в продакшені.
Таким чином, зв'язок між дизайном тестового засобу та надійністю конвеєра постійно недооцінюється під час оцінки інструментів, оскільки він невидимий у демонстраціях чи документації. Він стає очевидним лише в реальних умовах після впровадження.