Progressive Delivery Vocabulary: Feature Flags, Canary, and Blue-Green Explained (англійською)
Життєвий цикл прапорців можливостей, вага канарійки, розгортання кільця, перемикач аварійного завершення роботи, автоматичне повернення до попередньої версії — словник послідовних випусків, який вам потрібен для безпечних, контрольованих випусків англійською мовою.
Прогресивно-доставка є тим, як сучасні команди безпечно доставляють програмне забезпечення - не все одночасно, але поступово, з можливістю спостерігати, паузи і повернення. Словник прогресивного постачання з’ являється в обговореннях архітектури, runbooks, і планування випуску. Зрозуміти ці терміни допоможе вам чітко описати стратегію випуску і написати кращу документацію.
Флагманські функції
** Прапорець можливості ** (також * feature toggle * або * feature switch *) — Механізм налаштування, який увімкнув або вимкнув можливість під час виконання без розгортання нового коду. Прапорці відокремлюють розгортання (код доставки) від випуску (доступність для користувачів). Фраза: “Ми розгорнули новий поток вилучення за прапорцем можливості — за замовчуванням він темний, поки QA не підпишеться.”
** Цикл життя прапора ** — стадії, які проходить прапорець можливості: * створення * (коли додано прапорець), * визначення цілі * (починається розгортання), * повний випуск * (100% користувачів), * очищення * (прапорець вилучено з коду). Фраза: “Наша політика життєвого циклу прапорів вимагає видалення прапорів протягом двох спринтів повного випуску — застарілі прапори є тягарем для обслуговування.”
** Флаговий борг ** — Накопичення флагів можливостей, які так і не було очищено після повного випуску, що призвело до складної умовної логіки і непередбачуваних взаємодій. Фраза: “У нас є 40 старих прапорів в коді — борг за прапори робить тестування дуже складним.”
** Правила призначення ** — умови, які визначають, які користувачі бачать прапорець як увімкнений: за ІД користувача, відсотком, країною, рівнем плану, внутрішніми працівниками або за нетиповими атрибутами. Фраза: “Правило призначення вмикає функцію для користувачів на бета-плані тільки в Великій Британії.”
** Kill switch ** — Прапорець можливості, спеціально розроблений для швидкого вимикання проблемної можливості у виробничому середовищі без розгортання коду. Фраза: “Ми додали kill switch до рушія рекомендацій ШІ — якщо модель неправильно поводиться, ми можемо вимкнути її миттєво.”
Канарські острови
** Розгортання « канарійка » ** — стратегія, за якої нова версія отримує невеликий відсоток трафіку (* канарійка *), і цей відсоток збільшується, якщо показники залишаються стабільними. Названа за аналогією з канаркою у вугільному руднику. Фраза: “Ми почали канарку на 1% — якщо рівень помилок залишається нижче 0,1% протягом 30 хвилин, конвеєр підвищується до 10%.”
** Canary weight ** — відсоток трафіку, який буде маршрутизовано до версії canary. Фраза: “Важіння канарій на рівні 5% — ми піднімемо його до 25% після наступного вікна оцінки метрики.”
** Аналіз Canary ** — Автоматично або вручну порівнює показники між версією Canary і базовою (стабільною версією): частота помилок, затримка, використання процесора, показники бізнесу. Фраза: “Canary аналіз позначив підвищену затримку P99 на новій версії — підвищення було призупинено автоматично.”
** Підвищення ** — Перенесення версії canary на наступний рівень за відсотком трафіку або перетворення її на нову стабільну версію. Фраза: “Канарка пройшла всі ворота аналізу — підвищується до 100% зараз.”
** Автоматичний тригер відновлення ** — заздалегідь визначена умова (наприклад, частота помилок перевищує 1%), яка автоматично повертає трафік з версії canary до стабільної версії без втручання людини. Фраза: “Автоматичне відновлення тригера було викликано о 2 годині ранку — канарейка випускала помилки 5xx вище порогу.”
** Поріг частоти помилок ** — максимальна допустима частота помилок перед запуском автоматичного відновлення. Фраза: “Наша межа похибки для канарійного аналізу становить 0,5% — будь-що вище цього викликає автоматичне відновлення.”
Блакитний і зелений кольори символізують річку
** Синьо- зелене розгортання ** — Два виробничі середовища (* синій * = поточний, * зелений * = новий). Після перевірки нової версії, трафік змінюється з синього на зелений. Відновлення миттєве: повернути назад до синього. Фраза: “Ми робимо синій-зелений для платіжної служби — миттєве відновлення є вимогою, враховуючи профіль ризику.”
** Обмін слотами ** — у хмарних платформах, таких як Azure App Service, механізм перемикання трафіку між слотами розгортання (еквівалентний синє-зеленому обміну). Фраза: * “Запустити тести димової завіси на слот для перевірки перед запуском обміну слотами.” *
** Перехід на нову версію ** — момент, коли трафік перемикається зі старої версії на нову версію — або миттєво (синьо- зелений), або поступово (канарейка). Фраза: “Перехід трафіку відбувся о 14:00 UTC — всі метричні дані номінальні через п’ять хвилин.”
** Розгортання за кільцем ** — Стратегія, яка випускає зміни до послідовних кілець користувачів: внутрішні працівники → бета- користувачі → 10% → 50% → 100%. Кожне кільце є воротами перевірки. Фраза: “Кільце 0 є нашою власною інженерною командою — ми завжди готували їжу для собак на Кільці 0 перед розширенням.”
** Розділення трафіку ** — Розділення трафіку між двома або більше версіями за допомогою балансувальника навантаження, API- шлюз або мережа служб. Механізм, що стоїть за розгортаннями “Канарій” і “Синьо-зеленого”.
Словник інструментів
LaunchDarkly — популярна платформа керування функціями. Ключові терміни в інтерфейсі: targeting, variations, segments, environments, flag evaluation.
Unleash — система прапорців з відкритим кодом. Ключові терміни: * toggle *, * strategy * (поступове впровадження, userWithId), * environment *, * impression data *.
** Вправа: ** Написати план випуску для вигаданої можливості за допомогою поступового випуску. Включіть інформацію про те, яким інструментом прапора можливостей ви будете користуватися, як налаштувати правила призначення, якою буде ваша прогресія ваги канарки і який буде ваш автоматичний поріг відновлення. Використовуйте якомога більше слів з цієї статті.
«Смерть» (англ. Death) — «Смерть» (англ. Death) — «Смерть» (англ. Death) — «Смерть» (англ. Death) — «Смерть» (англ. Death)
Будьмо чесними; деякі з цих термінів - канарейка, кільце, блакитно-зелений - звучать вражаюче. Вони побудовані навколо ідеї складного контролю, що фантастично, але легко впасти в жаргон і втратити з виду основний принцип: ми хочемо мінімізувати ризик при випуску нового коду. Однією з областей, де цей нюанс особливо важливий для розробників, які вивчають англійську технічну лексику, є розуміння різниці між « rollback » і « kill switch ». Вони часто використовуються взаємозамінно, але вони представляють окремі дії з дуже різними наслідками.
- rollback * зазвичай означає повернення до попередньої версії розгортання — по суті, повернення до попередньої стабільної версії вашої програми. Цей спосіб зазвичай викликається проблемою, виявленою після випуску, наприклад, критичної вади або несподіваного зниження продуктивності. Метою не обов’язково є запобігання проблемі від того, щоб вона сталася в першу чергу; це про зменшення її негайного впливу. Розглядайте це як надзвичайний захід — « Ми відновили версію 2. 1. 3, оскільки користувачі повідомляли про періодичні помилки підключення до бази даних ». У запиті на звантаження ви можете побачити коментар, подібний до цього: « Відновлення було викликано через високу кількість помилок, спостережених після розгортання. Розслідування триває. ” Це реактивний крок, спрямований на швидке відновлення функціональності.
Однак, “kill switch” набагато більш радикальний. Це негайне і абсолютне вимкнення функції або, в деяких випадках, всієї програми. Якщо відновлення стосується певної версії, то перемикач аварійного завершення негайно зупиняє весь трафік до цього конкретного компонента. Уявіть, що інтеграція нового платіжного шлюзу зазнала катастрофічної невдачі — замість того, щоб просто повернути користувачів до старої системи (відновлення), ви можете скористатися перемикачами аварійного завершення, щоб запобігти * будь- яким * транзакціям, які проходять через помилковий шлюз, доки не буде вирішено проблему. Повідомлення Slack в цьому сценарії може звучати так: «Кілл-схема активована для функції X через серйозні проблеми з продуктивністю, що впливають на 50% користувачів. Команда інженерів проводить розслідування. “Це не про відновлення функціональності; це про запобігання подальшим пошкодженням і придбання часу для належного виправлення. Ключова відмінність полягає в * ступені * втручання - відновлення є цільовим, kill switch є повним припиненням.
Важливо чітко пояснити ці відмінності, особливо при обговоренні стратегій розгортання з зацікавленими сторонами, які можуть не бути технічно обізнаними. Використання точної мови уникає плутанини і забезпечує, що кожен розуміє обсяг дії, що виконується. Крім того, розуміння того, коли відновлення проти перемикачів знищення є відповідним, сильно залежить від вашої системної архітектури і налаштування моніторингу - знання * як * ви виявите проблему в першу чергу повідомляє правильну відповідь.
# Example: A simplified kill switch implementation (Conceptual - not production ready)
# This demonstrates a hypothetical command to disable a feature flag
# via a configuration file. In reality, this would be much more complex.
# Assume 'feature_flags.json' contains configurations like {"FeatureX": true}
import json
def disable_feature(feature_name):
try:
with open('feature_flags.json', 'r') as f:
data = json.load(f)
if feature_name in data:
data[feature_name] = False
with open('feature_flags.json', 'w') as f:
json.dump(data, f, indent=4)
print(f"Feature '{feature_name}' disabled.")
else:
print(f"Feature '{feature_name}' not found in configuration.")
except FileNotFoundError:
print("Configuration file not found.")
# Example usage (hypothetical):
disable_feature("FeatureX")