Feature Flags & Progressive Delivery Vocabulary: 25 Terms Explained (англійською)
Вивчіть словниковий запас функціональних прапорців для сучасної доставки — перемикачів, відсоткових розгортань, канарейкових випусків, перемикачів зупинки, боргів прапорців, LaunchDarkly, Unleash тощо.
Сучасні команди розробників більше не розгортають і моляться. Вони розгортаються поступово, функції ворота за прапорцями, і відновлюють негайно, якщо щось не так. Прапорці можливостей — також звані перемикачами можливостей або перемикачами можливостей — є основою цього підходу. Якщо ваша команда практикує розробку на основі ствола або поступове надходження, цей словник є необхідним для щоденних зустрічей, переглядів інцидентів і обговорень планування.
Основні поняття
Прапор функції (перемикач/перемикач)
Прапорець feature (також відомий як feature toggle або feature switch) — це умова у вашому коді, яка уможливлює або виключає функціональність без розгортання нового коду. Замість того, щоб робити зміни в коді, щоб щось ввімкнути, ви змінюєте налаштування.
“Ми відправили новий поток набору за функціональним прапорцем. Ми можемо ввімкнути його для певних користувачів без нового розгортання»
Життєвий цикл прапора
Кожен прапорець функціональності має свій життєвий цикл:
- ** Створити ** — визначити прапорець у вашій системі і записати умовний вираз у коді
- ** Enable ** — увімкнути, спочатку для невеликої групи
- ** Розгортання ** — поступово збільшувати відсоток користувачів, які бачать цей пункт
- ** Retire ** — після того, як функціональність буде повністю випущена, вилучити прапорець і умову з коду
“Цей прапор сидів у код-базі три місяці. Прийшов час вивести його на пенсію — вилучити умовний і очистити код»
Правило прицілювання
** Правило призначення ** визначає, хто бачить функцію. Правила можна налаштовувати за ІД користувача, доменом електронної пошти, країною, планом облікового запису або за будь- яким іншим атрибутом.
«Встановити правило призначення, щоб тільки користувачі на бета-плані бачили новий редактор — ми не готові випустити його для всіх»
Відсоток розгортання
** Процентне розгортання ** увімкує функціональність для визначеного відсотка користувачів, наприклад, 5%, потім 20%, потім 100%. Це обмежує радіус вибуху, якщо щось не так.
“Начните с 1% распространения. Якщо за наступну годину не з’явиться жодних помилок, збільште її до 10 %
Стратегия развертывания
Канарські острови
** canary release ** — це стратегія розгортання, за якої нова версія програми буде розгорнута для невеликої підгрупи користувачів (група * canary *) перш ніж для всіх інших. Назва походить від канарки шахтарів — системи раннього попередження.
“Ми робимо канарський випуск до 5% виробничого трафіку. Дивитися на рівень помилок і затримки — якщо щось підвищується, ми повертаємось назад»
Блакитно-зелене розгортання
У ** синє- зелене розгортання ** ви підтримуєте два ідентичні виробничі середовища — * синє * (поточне) і * зелене * (нове). Ви розгортаєтесь на зеленому, тестуєте, а потім переключаєте трафік з синього на зелений. Якщо виникнуть проблеми, ви відразу ж повернетеся до синього.
“Синьо-зелений дає нам нульовий час простою. Перемикання є миттєвим — просто зміна DNS або load balancer
Кільце розгортання
** Кільцеве розгортання ** випускає зміни через серію кілець — від внутрішніх співробітників, до бета- користувачів, до невеликого відсотка клієнтів і, нарешті, до всіх. Кожне кільце - це контрольний пункт.
«Наші кільця розгортання: внутрішні → 1% → 10% → 100%. Ми проводимо щонайменше 24 години в кожному колі»
Темний запуск
** Dark launch ** означає запуск нового коду у виробничому режимі для реального трафіку без показу результатів користувачам. Ви перевіряєте швидкодію і коректність нового шляху коду у тіні.
“Ми запустили новий двигун рекомендацій на два тижні. Він обробляв справжні запити, але ми відкидали вивід. Як тільки ми були впевнені, ми ввімкнули прапор»
Менеджмент ризиків
Перемикач знищення
** Kill Switch ** — це прапорець, спеціально розроблений для негайного вимикання функції у надзвичайних ситуаціях. На відміну від поступового розгортання, kill switch є двійковим — ввімкненим або вимкненим — і обслуговується інженерами по телефону, а не менеджерами продукту.
“В платіжній інтеграції є перемикач зупинки. Якщо він починає відмовлятися, переверніть перемикач і негайно поверніться до попереднього потоку»
Rollback
** rollback ** означає повернення до попереднього стану. За допомогою прапорців можливостей ви можете « відкинути » можливість, вимкнувши прапорець — не потрібно розгортання коду.
“Ми не повинні відкидати розгортання. Просто вимкнемо прапорець і користувачі отримають стару поведінку»
Технічні та гідрологічні умови
Золотий прапор
** Доля прапорців ** — це накопичена вартість прапорців можливостей, які ніколи не вилучаються. Старі прапорці заповнюють код, створюють плутанину щодо того, що було увімкнено, і можуть неочікувано взаємодіяти з новими прапорцями.
«Ми маємо 80 прапорів в код-базі і лише 20 з них все ще активні. Решта — борги за прапор — давайте заплануємо спринт очищення»
Розробка на основі ствола і прапори можливостей
У ** розробці на основі ствола *, всі розробники часто роблять спільний запит на одну головну гілку ( ствол *). Прапорці можливостей уможливлюють це, надаючи змогу об’ єднати і розгорнути незавершені можливості, не залишаючи їх видимими для користувачів.
“Ми не використовуємо гілки з довгою функцією. Ми злиємося в тунел щодня і використовуємо прапорці можливостей, щоб приховати роботу в процесі»
Флагманські платформи
LaunchDarkly
LaunchDarkly є провідною комерційною платформою для створення флагманських функцій. Він надає панель для керування прапорцями, правилами призначення і відсотками розгортання, з SDK для всіх основних мов і фреймворків.
«LaunchDarkly дозволяє команді продукту змінювати правила цільового призначення без залучення інженерів»
Unleash
Unleash — це платформа з відкритим кодом для флагманських функцій. Команди, які хочуть самостійно розмістити свою інфраструктуру, часто вибирають Unleash.
«Ми самостійно розміщуємо Unleash на нашій власній інфраструктурі — немає залежності від сторонніх сторін для оцінки прапора»
Flagsmith
Flagsmith є ще однією відкритою альтернативою LaunchDarkly, яка підтримує як розгортання на хмарі, так і самостійне розгортання.
Фрази спільних функцій прапорців
| Phrase | Meaning |
|---|---|
| ”Gate it behind a flag” | Don’t release it to all users — put a flag in front of it |
| ”Flip the flag” | Enable or disable the feature |
| ”The flag is stale” | The feature is fully released but the flag hasn’t been removed from the code |
| ”We can roll back without a deploy” | Turn off the flag to revert the behaviour |
| ”Gradual rollout” | Increasing the percentage of users who see the feature over time |
| ”The blast radius is limited” | Only a small percentage of users are affected if something goes wrong |
| ”Flag hygiene” | The practice of retiring old flags and keeping the flag inventory clean |
Розвиток «розумного» ринку в контексті «розумного» бізнесу
Термін «розгортання» - часто використовується при обговоренні функціональних прапорців - може бути на диво складним для не- рідних англомовних носіїв. Це часто представляється як просто «зробити функцію доступною для користувачів», але вона має значну кількість операційної і стратегічної ваги, особливо в команді розробників. Це не просто про розгортання коду; це про процес того, як зробити це розгортання впливовим. Поширене нерозуміння виникає від прирівнювання «розгортання» з простим натисканням кнопки «розгортання». Ця дія, звичайно, необхідна, але це лише перший крок у ретельно організованому плані.
Розглянемо такий сценарій: Під час перегляду коду старший інженер може прокоментувати опис PR, сказавши: « Цей випуск виглядає добре концептуально, але нам потрібно додати більше деталей про цільовий сегмент користувачів для цього випуску, заснованого на відсотках — давайте прояснимо, що становить « критичні » користувачі, перш ніж ми продовжимо ». Це не критика; це спостереження, що підкреслює * стратегію * за випуском. Інженер просить глибшого розуміння того, чому ця конкретна група є цільовою, і як буде вимірюватися успіх. Аналогічно, в Slack ви можете побачити повідомлення на кшталт: «Відкриття v2 для 10% користувачів сьогодні післяобідньо – ретельне моніторинг ключових показників». Наголос тут не тільки на дії; це про постійне спостереження і адаптацію. Погано визначений rollout може швидко стати «боргом прапора», накопичуючи невикористані прапори і ускладнюючи майбутні розгортання.
Крім того, концепція «поступового впровадження» часто неправильно трактується. Це не означає просто розгортання до 1% спочатку. Це означає ретельний контроль над тим, хто бачить функцію, коли вона з’ являється і як її продуктивність контролюється на кожному етапі. Успішне розгортання не стосується сліпого просування коду; це стосується ітеративного навчання і зменшення ризику. Це вимагає чіткого розуміння ваших показників - коефіцієнтів перетворення, рівнів помилок, залучення користувачів - і здатності швидко реагувати, якщо щось не так (отже, важливість наявності «kill switch»).
Проілюструймо це на прикладі з використанням LaunchDarkly :
launchdarkly set feature-name=true segment="new_users" region="us-east-1"Ця команда, хоча і здається простою, але вона являє собою навмисну дію — встановлення прапора для певного сегмента у певній області. * rollout * це не просто сама команда; це весь процес визначення цього сегмента, моніторингу його впливу і коригування стратегії розгортання на основі цих спостережень. Це розуміння того, як реагують різні сегменти, і забезпечення того, що функція забезпечує цінність для запланованих користувачів.