Англійська для LaunchDarkly Feature Flags

Прапорці можливостей дозволяють вам відокремити розгортання коду від його випуску, але це добре працює лише як командна практика, якщо всі використовують однаковий словник для призначення, варіацій і відновлення — інакше « вимкнути прапорець » може означати п’ ять різних речей залежно від того, хто це каже.

Ключовий словник

Variation Flag — одне з можливих значень, які може обслуговувати прапорець (часто true / false, але може бути рядком, числом або об’ єктом JSON), оцінюваних за запитом на основі правил призначення. “Це не просто прапорець включення/виключення — він має три варіанти, які керують тим, який з трьох розкладок замовлення буде показано користувачеві.”

** Правило призначення ** — умова (заснована на атрибутах користувача, таких як рівень плану, регіон або відсоток розгортання), яка визначає, який варіант буде надано певному користувачеві або запитові.

• “Ми додали правило призначення, яке обслуговує новий варіант тільки для користувачів у корпоративному плані в ЄС, щоб ми могли спочатку перевірити його з контрольованою аудиторією.” *

** Розгортання за відсотками ** — правило призначення, яке розподіляє трафік між варіантами за відсотками, а не за явними атрибутами, використовується для поступового розширення доступу до нової можливості. “Ми зараз на 25% розгортання - якщо рівень помилок залишиться стабільним ще один день, ми піднімемо його до 50% і будемо спостерігати, перш ніж перейти до 100%.”

** Kill switch ** — прапорець (або вимкнений стан прапорця), який використовується спеціально як аварійний механізм для миттєвого вимикання можливості у виробничому режимі без розгортання або відновлення коду. “Ми переключили аварійний вимкнути в той момент, коли новий платіжний провайдер почав робити помилки - це зайняло тридцять секунд, порівняно з десятьма хвилинами, які були б потрібні для повного відновлення.”

** Прапорець попередніх вимог ** — прапорець, налаштований так, щоб залежати від стану іншого прапорця, отже, його власні правила призначення діють лише у тому випадку, якщо прапорець попередніх вимог також обслуговує певний варіант. “Новий прапорець панелі приладів має перероблений прапорець навігації як попередню умову — немає сенсу вмикати один без іншого, тому ми встановили цю залежність безпосередньо у налаштуваннях прапорця.”

Звичайні фрази

• «Скільки варіантів має цей прапор, і що визначає, який з них отримує користувач?»
• Чи є це правило таргетування засноване на атрибуті користувача, або на відсотковому розгортанні?»
• «Який відсоток ми зараз маємо, і який план для зростання?»
• Чи є в цьому додатку перемикач знищення, якщо щось пішло не так після повного розгортання?»
• Чи має цей прапор передумову, чи може він бути перемкнений незалежно?»

Приклади висловлювань

Пропозиція плану розгортання у документі проекту: “Ми розпочнемо з 5% відсотка розгортання, націленого тільки на внутрішні облікові записи, розширимо до 25% всіх користувачів після 24 годин чистих метрик, а потім перейдемо до 100% - з готовим до зупинки на кожному етапі.”

Пояснення рішення про перегляд: “Це правило призначення обслуговує новий варіант тільки для користувачів з більше ніж десятьма проектами, оскільки це сегмент, який найбільше схильні до проблеми з швидкодією, яку ми виправляємо.”

Відповідь під час інциденту:

• “Вмикання вимикача аварійного відключення зараз — це негайно повертає всіх до старого варіанту, дає нам час для зневадження, щоб користувачі не бачили пошкодженої поведінки.” *

Професійні поради

• Назвіть ** варіант прапора ** явно, коли повідомляєте про помилку, пов’ язану з прапором — « нова функція пошкоджена » набагато менш корисна, ніж « варіант B прапора замовлення не працює для користувачів ЄС. »
• Зазначте логіку правила таргетування чітко, коли пропонуєте розгортання — “ми включимо його для деяких людей” запрошує плутанину; “25% випадкове розгортання, без таргетування атрибутів” не робить цього.
• Завжди переконуйтесь, що ** kill switch ** існує і перевіряється перед тим, як ризикований прапорець перейде на 100% — виявлення того, що немає швидкого способу вимкнути пошкоджену функцію в середині інциденту, є поганим часом для вивчення цього.
• Відстежуйте ** відсоткові стадії розгортання ** і їхні критерії виходу в самому плані розгортання - “ми розширимо його пізніше” без зазначеного порогу, як правило, затримується на неопределенное час на будь-якому відсотку, який відчуває себе комфортно.

Практичні вправи

1. Напишіть речення, у якому буде пояснено різницю між правилом призначення і відсотковим розгортанням.
2. Опишемо сценарій аварійного вимикання і чому швидкість тут важлива.
3. Поясніть вашими словами, що таке прапорець попередньої умови.

Навигація Nuance: Функція Flag дискусії в командному спілкуванні

Будьмо чесними – навіть з чітким розумінням * правил націлення * і * варіантів *, ефективне спілкування про прапорці функцій LaunchDarkly може стати складним. Сама мова точна, але перекладання цієї точності в природну розмову, особливо при співпраці між командами або поясненні рішень зацікавленим сторонам, які не є глибоко технічними, вимагає ретельної фразування. Це не просто заява фактів; це передавання наміру і забезпечення того, щоб кожен розумів наслідки.

Одна з найпоширеніших проблем виникає під час перегляду коду. Уявіть, що ви отримуєте коментар щодо запитів на збирання, що реалізують новий варіант прапора можливості: « Це виглядає добре, але чи можете ви розібратися у стратегії розгортання? Зокрема, чому ми використовуємо цю конкретну варіацію проти типової? ” Прямий переклад “Яка логіка за цим правилом прицілювання?” Може здатися надто формальним і потенційно залякуваним. Замість цього, більш доступною формулюванням було б: «Тільки для пояснення - я бачу, що ми вводимо цей варіант для [коротко вкажіть запланований випадок використання]. Можешь объяснить мне логику, лежащую в основе этого решения? Це допомагає мені зрозуміти, як вона інтегрується з загальним розгортанням можливостей. » Аналогічно, якщо ви пояснюєте реалізацію * kill switch *, сказати « Ми вимикаємо цю можливість » буде занадто тупо. Замість цього, «Ми реалізували kill switch, щоб негайно зупинити розгортання цього варіанту на випадок, якщо ми спостерігаємо несподівані проблеми» звучить більш професійно і підкреслює проактивне зменшення ризику.

Іншою областю, де нюанс має значне значення, є розмови Slack. Розробник може надіслати повідомлення: « Розгортання прапора « бета » з аудиторією 20% ». Людина, для якої мова не є рідною, може негайно інтерпретувати це повідомлення як просто відсоток користувачів. Однак, важливо розуміти, що «20%» відноситься до * початкового розгортання * - тобто 20% загальної бази користувачів будуть спочатку піддані новому варіанту. Більш чіткою формулюванням може бути: « Розгортання прапора « бета » з початковою аудиторією 20%, що дозволить нам стежити за продуктивністю перед більш широким випуском ». Це підкреслює керований і спостережуваний характер розгортання, що є ключем до успішного впровадження прапора можливостей.

Нарешті, при написанні описів PR, уникайте жаргону. Замість того, щоб сказати «Ми використовуємо динамічне таргетування», спробуйте «Ця PR вводить новий варіант функціонального прапора, який дозволяє нам тестувати цю функціональність з невеликою підмножиною користувачів перед її широким випуском».

launchdarkly flags create --name myFlag --variation myVariation --target-segment "user_id:12345" --environment production

Ця проста команда показує, як за допомогою LaunchDarkly ви можете точно визначити * правило призначення * на основі атрибутів користувача, що є ключовою концепцією під час обговорення стратегій прапорців можливостей. Це фундаментальний елемент у розмовах про контроль доступу до функцій і моніторингу продуктивності.