Деплоїти в прод при кожній зміні може бути моторошно, але не деплоїти одразу в прод — ще моторошніше.
Це процес, який я впровадив в Amazon, керуючи командою, що деплоїла для сотень мільйонів клієнтів. Завдяки консалтингу я допомагав інженерним командам перейти від планових релізів раз на два тижні до деплою при кожному мерджі.
Почнімо з очевидного:
Ви спричините збій. Це не питання «якщо», а питання «коли».
Жодна кількість юніт-тестів, інтеграційних тестів, догфудингу, будь-яких там end-to-end чи жертв богам деплою не виловить усі баги.
Тестування, яке ви проводили для своєї фічі тиждень тому, не враховувало найсвіжіших змін вашого колеги.
Ваше тестування проводилося проти передпродової версії сервісу колеги, яка відтоді змінилася й тепер містить зворотно несумісну зміну.
Що довше ви чекаєте, то більше змін накопичується в релізі. Якщо вам знадобиться відкат, ви відкочуватимете два тижні змін, а не роботу за 1–2 години.
Якщо ми приймаємо той факт, що збій неминучий, набагато менше сенсу вкладати величезні ресурси в QA релізу. Натомість варто зосередити ресурси на моніторингу та спостереженні за релізом і бути готовими реагувати на збій, коли він станеться.
Тепер перейдімо до того, як цього досягти:
Передумови:
CI/CD
Тестування має набагато менше значення, ніж ви думаєте. Тести не можуть довести, що ваша зміна безпечна в продакшені. Ніщо не може. Тести лише роблять збій дешевим. Баг, спійманий у CI, коштує хвилин. Баг, спійманий у продакшені, коштує вам вечора, проведеного за відкатом.
Тож запускайте повний набір тестів на кожен мердж або принаймні як частину пайплайну: юніт, інтеграційні, end-to-end тести. Що далі по пайплайну просувається баг, то дорожче його виправляти.
Моніторинг / спостережуваність
Суть гри — зловити регресію якомога швидше. Щоб цього досягти, вам потрібен відмінний моніторинг. Він має такий вигляд:
- метрики: помилки, затримка, доступність
- логи з кореляційними ID
- алерти для sev-3 і sev-2 (пейджинг), налаштовані на основі двох пунктів вище
У налаштуванні порогів алертів є трохи мистецтва й науки. Це баланс між чутливістю та швидкістю вашої реакції на реальний інцидент. Ваш цільовий час від sev-2 до сповіщення має становити 5–10 хвилин.
Спочатку ви, найімовірніше, помилятиметеся й будете занадто чутливими. На жаль, цьому вчаться здебільшого методом проб і помилок, тож перший час вас, імовірно, будитимуть о 2-й ночі.
Фіча-флаги
Будь-яку ризиковану зміну варто випускати за фіча-флагом або віддаленою конфігурацією. Фіча-флаг дозволяє відкотити й вимкнути будь-яку зміну за кілька хвилин, а не відкочувати весь деплой. До того ж, якщо ваш сервіс фіча-флагів це дозволяє (а мав би), ви можете поступово вмикати фічу відсотково або за когортами, ще більше знижуючи вплив поганої зміни.
Це дозволяє нам розділити розгортання коду й активацію коду. Нюанс, але він змінює правила гри для зниження ризиків.
Примітка: вам знадобиться процес для очищення цих флагів. В ідеалі створюйте тікет на видалення для кожного створеного флага. Інакше, коли ваш сервіс фіча-флагів упаде (а він упаде), ви отримаєте значну регресію. Запитайте мене, звідки я знаю.
Автоматичний відкат (запобіжник на час деплою)
Запобіжник на час деплою — це функція, яка дозволяє відкотити розгортання, якщо ви бачите кількість або відсоток помилок під час розгортання на всю інфраструктуру. Більшість хмарних провайдерів тепер пропонують це однією галочкою.
Зворотно сумісні зміни
Вам варто було вже так робити, але деплой на кожен коміт змушує до цієї практики. Під час поетапного розгортання стара й нова версії працюватимуть одночасно. Кожна зміна має працювати поруч із попередньою версією. Ваш трюк із деплоєм опівночі, щоб уникнути цього, більше не працює.
Стратегії розгортання
Отже, маючи все це, розгляньмо кілька стратегій розгортання, які допоможуть знизити ризики під час випуску змін.
Одна машина (канарка)
Канарковий деплой розгортає ваші зміни на одній машині в більшому кластері. Це дозволяє обмежити вплив будь-якої поганої зміни лише одним хостом.
Ви деплоїте й даєте цьому постояти певний час, отримуючи невелику частку загального трафіку. На цій машині налаштовані моніторинг та алерти, які спрацюють, якщо щось зламається.
Поетапне розгортання
Поетапне розгортання дозволяє випускати зміни відсотково протягом часу, щоб у разі катастрофічної помилки ви встигли її зловити, перш ніж вона вдарить по всіх машинах, і почали відкат.
Регіональний випуск
Зі зростанням вашої компанії ви зрештою матимете мультирегіональні розгортання. Замість того щоб деплоїти в усі регіони одночасно, можна спершу задеплоїти в один конкретний регіон (зазвичай із найменшим трафіком).
Випадки, де це не працює
App Store
Випуск мобільного застосунку не зовсім сумісний із цими порадами. Черга рев'ю в App Store стримує ваш темп деплою й потребує іншої стратегії.
Сертифіковані середовища
Медичні пристрої, авіоніка, промислові системи керування тощо. Не можна деплоїти безперервно, якщо потрібна сертифікація збірки регулятором.
On-prem / Self-hosted
Ви не контролюєте оновлення. Ви все ще можете безперервно деплоїти все, чим керуєте, але кожна зміна має бути версіонована, а клієнт вирішує, коли її впровадити.
З чого почати
Не робіть усе це одразу. Порядок має значення:
- Зробіть CI зеленим і швидким. В ідеалі менше 15 хвилин
- Додайте метрики й алерти на рівень помилок, затримку та доступність. Це найважливіша частина процесу
- Ховайте будь-яку ризиковану зміну за флагом
- Додайте канарковий деплой + автоматичний відкат
- Видаліть календар релізів
- Знайдіть нове застосування всьому вашому додатковому часу, тепер коли ви не плануєте релізи
Більшості команд, із якими я працював, потрібно близько кварталу, щоб пройти цей шлях. Інструменти — це легка частина. Організаційний процес і руйнування ілюзії, що планові релізи безпечні, — ось що складно.
Якщо ваша команда сидить на календарі релізів і хоче з нього зійти, це саме та робота, яку я роблю. Пишіть мені в DM.
