Feature flags: deploy to nie release
- data
- kategoria
- CI/CD
- także w
- Reliability Engineering
- czytanie
- 1 min / 185 słów
Rolling update, blue-green i canary nadal często zakładają jedno:
nowa wersja kodu oznacza nowe zachowanie
Feature flags powstały, żeby rozdzielić te dwa momenty.
deploy kodu
release funkcji
Kod może być już w produkcji.
Funkcja może być nadal wyłączona.
Minimalny przykład
Najprostsza flaga to konfiguracja.
apiVersion: v1
kind: ConfigMap
metadata:
name: api-config
data:
FEATURE_FAST_CHECKOUT: "false"
Aplikacja czyta wartość:
const fastCheckoutEnabled =
process.env.FEATURE_FAST_CHECKOUT === "true";
if (fastCheckoutEnabled) {
return newCheckout(request);
}
return oldCheckout(request);
To jest prymitywne.
Ale pokazuje mechanizm:
ten sam artefakt
inne zachowanie
W prawdziwym systemie flaga może zależeć od użytkownika, tenanta, regionu albo procentu populacji.
Do czego to realnie służy
Feature flags dają trzy użyteczne rzeczy.
Pierwsza to oddzielenie deploy od release.
Można wdrożyć kod wcześniej, a funkcję włączyć później.
Druga to kill switch.
Jeżeli funkcja psuje system, wyłączenie flagi może być szybsze niż rollback obrazu kontenera.
Trzecia to progressive delivery.
Ta sama flaga może zasilać:
internal rollout
beta rollout
ringi
A/B test
stopniowe włączanie procentem
Gdzie nazwa kłamie
Feature flag brzmi jak mały przełącznik.
W praktyce jest rozgałęzieniem kodu.
Każda flaga zwiększa liczbę możliwych stanów:
stara ścieżka
nowa ścieżka
częściowo włączone zależności
różne grupy użytkowników
Flaga bez planu usunięcia staje się trwałą architekturą.
Po kilku miesiącach nikt nie wie, czy można skasować starą ścieżkę.
Deploy to nie release
Najważniejsza lekcja jest prosta.
Deployment mówi:
nowy kod jest w środowisku
Release mówi:
użytkownik widzi nowe zachowanie
Feature flags pozwalają rozdzielić te zdania.
To jest potężne, jeśli flaga ma właściciela, cel i datę sprzątania.
Bez tego flaga jest tylko długu technicznego z ładną nazwą.