Коли говорять про автоматизацію релізів, майже завжди мають на увазі шлях уперед: як швидше зібрати, як гладше викотити, як довести деплой одним натиском. Це важливо. Але за роки я зрозумів просту річ: найцінніша автоматизація — не в тому, як швидко ти викотиш, а в тому, як швидко й спокійно ти зможеш повернутись назад.
Логіка проста. Деплой уперед ти робиш у робочий час, свіжий, з планом, з увагою всієї команди. Відкат ти робиш у найгіршу мить — коли вже щось горить, коли на тебе дивляться, коли адреналін заважає думати. Саме цей момент найбільше потребує автоматизації, а на практиці саме він найчастіше лишається ручним і страшним.
Я бачив команди з ідеальним CI/CD уперед і повним хаосом назад. Викотити нову версію — одна кнопка. Відкотити — знайти попередній тег, згадати міграції бази, вручну поправити фіче-флаги, помолитись. У результаті люди боялись відкочуватись. А коли боїшся відкату, ти сидиш і терпиш зламаний реліз, замість того щоб за тридцять секунд повернути робочий. Страх відкату — це прихований податок на кожен деплой.
Тому я став вимірювати релізну зрілість одним питанням: скільки часу й скільки ручних кроків між «щось пішло не так» і «ми знову на попередній робочій версії». Якщо відповідь — хвилини й один-два кроки, команда сміливо релізиться часто. Якщо це півгодини паніки, вона релізиться рідко й великими шматками, а великі релізи — це саме те, що складніше й небезпечніше відкочувати.
Практично це означає кілька речей. Відкат — така сама автоматизована операція, як деплой, з тією самою однією кнопкою. Міграції бази сумісні назад, щоб стара версія коду працювала з новою схемою. Фіче-флаги, щоб вимкнути проблемну поведінку без повного відкату. І здоровий інстинкт: спершу поверни користувачам робочу систему, а вже потім розбирайся, що саме зламалось.
Стійка релізна система — це не та, де ніколи не викочують багів. Баги будуть завжди. Це та, де від зламаного релізу до робочого — тридцять спокійних секунд, а не година страху.
– Sergey Shinder
