«Рухатися швидко» і «не ламати продакшн» суперечать одне одному лише тоді, коли релізи великі, непрозорі й незворотні. Регулярні релізи — це радше питання практики, ніж інструментів.
Продуктова розробка для команд, що ростуть, — це баланс між обіцянками клієнтам і технічною реальністю. Найшвидшими часто здаються ті команди, які щодня випускають невеликі зміни й можуть точно пояснити, що змінилося.
Малі порції кращі за великі вибухи
Прапорець функції не замінює нарізання роботи на частини. Мета — безперервно вливати цінність: зміни схеми зі зворотною сумісністю, інтерфейс за прапорцями лише за потреби й міграції, які можуть виконатися раніше за код, що від них залежить.
Зробіть відкат м’язовою пам’яттю
Якщо для скасування деплою потрібен цілий штаб, ви випускатимете рідше. Інструкції на випадок збоїв, перевірки справності й артефакти деплою мають виходити з того, що відкат трапляється регулярно, а не лише під час катастроф.
- За можливості одна логічна зміна на реліз.
- Автоматичні смоук-тести на шляхах, які приносять дохід або створюють навантаження на підтримку.
- Моніторинг помилок і затримок, прив’язаний до позначок релізів.
Стабільність — це не менше релізів. Це передбачувані релізи з відомим радіусом ураження.
Комунікація — частина системи
І внутрішні інструменти, і клієнтські продукти зазнають невдачі, коли зміни стають несподіванкою для тих, хто з ними працює. Короткі нотатки до релізу, видимі журнали змін для адміністраторів і тестові середовища з обмеженнями продакшну зменшують кількість «на моїй машині працює» під час запуску.
Саме так ми працюємо над клієнтськими проєктами й над власними продуктами; на сторінці як ми створюємо продукти це описано крок за кроком.
Регулярні релізи дають бізнесу змогу рости, не боячись власного програмного забезпечення. Практики непоказні, а от результат (команди, які щотижня покращують продукт без драм) — навпаки.