Найкращий тест для CI/CD-пайплайну — це не зелений білд. Це момент, коли половина команди пішла, прийшли нові люди, а пайплайн усе одно працює й ніхто не боїться натиснути кнопку деплою. Саме тоді видно, чи ти будував систему, чи просто збирав купу скриптів, які тримались на одній людині в голові.
У мене був проєкт, де весь реліз знав лише один інженер. Він тримав у пам'яті, який job запускати першим, де підправити змінну, коли ретраїти впалий крок. Поки він був на місці, все летіло. Коли він пішов у відпустку на два тижні, ми не могли викотити навіть хотфікс. Пайплайн формально існував, але фактично його не було — була людина, яку назвали пайплайном.
Ми переписали все з однієї простою вимогою: новий інженер має викотити реліз у перший тиждень, читаючи лише README і дивлячись на самі кроки. Ніяких усних інструкцій. Кожен крок пайплайну сам говорить, що робить і чому падає. Помилки перестали бути «щось зламалось» і стали «ось цей контракт не виконано, ось як полагодити».
Це і є стійкість пайплайну — не кількість стадій і не модні інструменти, а здатність системи пережити зміну людей навколо неї. Команди течуть постійно: хтось приходить, хтось іде, хтось вигорає. Пайплайн, прив'язаний до однієї людини, — це не автоматизація, це відкладений інцидент.
Практично я перевіряю це трьома питаннями. Чи може новачок запустити реліз без мене? Чи зрозуміло з логів, що зламалось, без пошуку по чату? Чи однакова поведінка пайплайну локально й на CI? Якщо хоч одне «ні» — там сидить майбутній збій, просто ще не спрацював.
Я більше не вимірюю CI/CD швидкістю. Я вимірюю його тим, наскільки спокійно система переживає зміни навколо себе. Швидкий пайплайн, який знає лише одна людина, — це ілюзія швидкості. Повільніший, але зрозумілий будь-кому, — це те, на що можна спертись у поганий день.
– Sergey Shinder
