OpenFeature and Feature Flags: English Vocabulary for Progressive Delivery (англійською)
Побудуйте англійський словник, який вам потрібен для обговорення прапорців можливостей, послідовних розгортань і стандарту OpenFeature CNCF у розмовах інженерної команди.
Функціональні прапорці змінили те, як інженерні команди доставляють програмне забезпечення. Замість великих випусків, команди впроваджують зміни поступово, тестують з підмножинами користувачів і негайно знищують проблемні функції без розгортання. Але щоб брати участь у цих розмовах — на зустрічах з планування, перегляді коду, і післясмертних розмовах — вам потрібен правильний англійський словник. Ця стаття описує все, починаючи з основної концепції і закінчуючи стандартом OpenFeature CNCF.
Основні характеристики флага
** Feature flag ** (також: ** feature toggle **) — умовна перевірка коду, яка вмикає або вимикає функціональність під час виконання, без розгортання нового коду. Термін «прапор» походить від бінарної природи включення / виключення оригінальної концепції.
«Ми відправляємо новий поток оплати за прапорцем функції, щоб ми могли ввімкнути його для внутрішніх тестерів спочатку, перш ніж розгорнути його для всіх користувачів»
** Feature toggle ** — старий, взаємозамінний термін для прапора можливості. Деякі команди віддають перевагу «toggle», тому що це краще описує поведінку перемикання ввімкнення/вимикання. Ці два терміни використовуються синонімно в більшості кодових баз.
«Прем’єр-міністр попросив нас ввімкнути темний режим тільки для бета-користувачів — це вже в коді, просто заблоковано перемикачем»
** Прогресивно розгортання ** — стратегія розгортання, за якої функціональність поступово увімкнено для більшої кількості користувачів протягом певного часу, що дозволяє командам стежити за проблемами до повного випуску.
«Ми робимо поступове впровадження: 1% трафіку сьогодні, 10% завтра, 50% до п’ятниці, якщо рівень помилок залишається стабільним»
** Canary release ** — тип поступового випуску, коли невелика група користувачів отримує нову версію першою. Якщо не виникає проблем, випуск розширюється. Назва походить від історичного використання канарій у вугільних шахтах як систем раннього попередження.
«Вийшов канарський випуск, який показав 3x збільшення відмови від покупок для цього сегмента користувачів — ми негайно підняли прапор»
** Kill switch ** — прапорець можливості, який використовується спеціально для швидкого вимикання можливості у виробничих умовах без відновлення коду. У кожної важливої функції має бути одна.
“Ми доставили інтеграцію платіжного провайдера з перемикачем зупинки. Коли у них був відключення у вівторок, ми перевернули його за 30 секунд»
Відкриті функції та терміни інструментів
** OpenFeature ** — відкритий стандарт CNCF (Cloud Native Computing Foundation), який визначає нейтральний для виробника API для прапорців можливостей. Це дозволяє командам перемикатися між постачальниками, такими як LaunchDarkly, Flagsmith або Unleash, без переписування коду їхніх програм.
«Ми прийняли OpenFeature, тому ми не заблоковані в LaunchDarkly — якщо ми перейдемо на Flagsmith наступного року, ми оновимо тільки постачальника SDK, а не виклики оцінки»
** Контекст оцінки ** — дані, передані до SDK прапора можливості під час оцінки прапора. Зазвичай містить ІД користувача, регіон, рівень плану або інші атрибути призначення.
«Передавати рівень підписки користувача в контексті оцінки, щоб система прапорів могла застосовувати різні правила для безкоштовних і платних рахунків»
** Правило призначення ** — умова, яка визначає, які користувачі або середовища бачать прапорець як увімкнений. Правила можна налаштовувати на певні ІД користувачів, відсоток трафіку, регіони або нетипові атрибути.
Додати правило таргетування, яке вмикає функцію для будь-кого з електронною поштою, що закінчується на @company.com — це наша внутрішня група собачих кормів
** Цикл життя прапора ** — стадії, які проходить прапор можливості: створення, розгортання, повне випуск і, зрештою, вилучення. Застарілі прапори, які ніколи не вилучаються, накопичуються як технічний борг.
«У нас є 40 прапорів у виробництві, які постійно активовані і ніколи не були очищені. Керування життєвим циклом прапора зараз на дорозі Q3»
** Розробка за допомогою прапорців, заснована на корені ** — стратегія розгалуження, за якої всі розробники часто виконують commit до головної гілки, використовуючи прапорці можливостей для приховування незавершеної роботи замість гілок з довготривалими можливостями.
“Ми перейшли до розробки на основі ствола минулого року. Прапори можливостей замінили наші двотижневі гілки можливостей — конфлікти злиття різко впали»
Контекстно-орієнтовані мови
- ** « Прапорець запускається у темному режимі, але ще не увімкнено для жодного користувача. » ** — оновлення стану у режимі standup, тобто код розгорнуто, але ніхто його ще не бачить
- “Ми повинні очистити прапори від міграції Q1 — вони всі назавжди правдиві зараз.” — технічна дискусія про борг в ретроспективі спринту
- ** « Чи можете ви додати правило призначення, щоб увімкнути це для ідентифікаційних кодів користувачів команди контролю якості? » ** — запит під час перегляду коду або зустрічі з розгортанням
- “Оцінка прапорців відбувається на стороні сервера, а не на стороні клієнта — немає мігнання інтерфейсу користувача.” — пояснення архітектури в огляді дизайну
- “Ми на 25% розгорнуті, а затримка p95 залишається незмінною — я підніму її до 50% після ранкової пікової напруги.” — оновлення стану розгортання в Slack
Ключові слова
| Collocation | Example |
|---|---|
| flip a flag | ”Flip the flag back to false — we’re seeing errors in the EU region.” |
| roll out a feature | ”We’ll roll out the feature to 10% of users starting Monday.” |
| enable for | ”Enable the new dashboard only for beta users initially.” |
| gate behind a flag | ”All new payment methods must be gated behind a flag at launch.” |
| stale flag | ”That stale flag has been true for eight months — time to remove the conditional.” |
| evaluate a flag | ”The SDK evaluates the flag on every request using the user’s context.” |
| percentage rollout | ”Start with a 5% percentage rollout and monitor the error rate.” |
Practice
Посмотри на последний фильм, который выпустила ваша команда. Напишіть короткий абзац англійською мовою (5- 7 речень), у якому описайте, як ви б використовували прапорець можливості для поступового випуску. Уключіть: що буде позначено прапорцем, які будуть правила визначення цілі, який відсоток розгортання ви плануєте виконати, і які параметри вкажуть вам, що безпечно перейти до 100%. Використовуйте принаймні п’ ять слів з цього матеріалу. Такий спосіб написання безпосередньо відображає те, що ви вкладаєте у технічний документ з проектування або підручник з розгортання.
Перегляд коду: Перегляд коду
Ядро цінності OpenFeature полягає не тільки в розгортанні можливостей; це управління ризиками і полегшення співпраці. Коли ви працюєте з командами, особливо з тими, що працюють з різними мовними середовищами, чітке спілкування щодо прапорців можливостей є абсолютно критичним. Часто початкове захоплення новим розгортанням може швидко віддати місце занепокоєнню - і ці занепокоєння часто висловлюються через коментарі перегляду коду, які самі по собі можуть бути мінним полем для не-рідних мовців, які намагаються розшифрувати намір.
Припустимо, що я зробив PR, вводячи прапор, який називається new_user_onboarding. Рецензент може залишити коментар на зразок: « Чи можете ви розкрити логіку, яка стоїть за цим прапором? Це здається трохи різким. » Або, можливо, « Чи є якась документація, яка пояснює, що викликає цей прапорець? » Ці коментарі не обов’ язково є критикою самого коду; вони представляють спробу зрозуміти * чому * рішення було прийнято і як воно збігається з більш широкою інженерною стратегією. Формулювання навмисно обережне — «здається трохи різким» не є прямим звинуваченням в поганому дизайні, а скоріше сигналом, що потрібне подальше пояснення. Аналогічно, запит на документацію підкреслює необхідність прозорості і доступності інформації. Розробник, який не знайомий з контекстом, може неправильно інтерпретувати назву простого прапора як потенційно небезпечну, не розуміючи його призначеної мети у рамках стратегії розгортання.
Хороша відповідь на такий відгук не просто про оборонне обґрунтування зміни, а про активне забезпечення ясності. Щось на зразок: « Дякую за те, що підняли цю тему! Прапорець new_user_onboarding є частиною нашого поступового розгортання, розробленого для поступового відкриття нового потоку введення до 10% користувачів протягом тижня. Ми ретельно стежимо за ключовими показниками - ступенем конверсії і ступенем помилок - протягом цього періоду. Я додав коментар до PR, де детально пояснювався план розгортання, і ми можемо запланувати короткий чат, щоб пройти через це, якщо це буде корисним. “Ця відповідь визнає занепокоєння рецензента, пояснює основне обґрунтування за допомогою технічної термінології (прогресивно розгортання) і пропонує матеріальну підтримку - документацію і обговорення - демонструючи відкритість до співпраці.
Ось приклад того, як це може перетворитися на повідомлення Slack при обговоренні того ж питання: «Гей команда, просто хотів пояснити прапорець new_user_onboarding. Ми використовуємо його для контрольованого розгортання до 10% спочатку, що дозволяє нам вловити будь-які проблеми перед більш широким випуском. Я добавил подробные примечания к PR о показателях, которые мы будем отслеживать и плане отката, если потребуется. Дайте мені знати, якщо у вас є якісь запитання!»
# Example CLI command (using a hypothetical OpenFeature tool) - demonstrating monitoring
openfeature monitor --flag new_user_onboarding --metric conversion_rate --period 1hЦя команда демонструє використання openfeature для активного моніторингу розгортання і підкреслює, як рішення, що базуються на даних, є центральними для ефективного керування прапорцями функцій. Ключовим моментом є те, що ефективне спілкування навколо функціональних прапорців стосується не тільки технічної точності; це про будівництво довіри, сприяння розумінню і проактивне вирішення потенційних проблем - особливо для тих, хто пересувається новою мовою і набором інженерних практик.