Feature Flags als Methode zur Deployment-Risikominimierung
Wochen Entwicklungsarbeit, abgeschlossenes Code-Review, alle Tests grün. Das Feature gelangt in die Produktion – und innerhalb einer Stunde treffen Fehlerberichte ein. Der Code verhält sich für die meisten Nutzenden korrekt, aber bestimmte Produktions-Szenarien, die im Staging nicht aufgetreten sind, führen bei einem Teil der Nutzenden zu Ausfällen. Das Ergebnis: ungeplanter Rollback, Incident-Dokumentation, Ursachenanalyse.
Feature Flags verhindern genau das. Das Prinzip: Deployment und Release werden entkoppelt. Code gelangt in die Produktion, sobald er bereit ist – wer das neue Feature tatsächlich sieht, wird unabhängig davon über einen Schalter in GitLab gesteuert. Kein Redeployment, kein Hotfix, keine ungeplante Rollback-Prozedur.
Systematisch gesteuerte Rollouts
Der eigentliche Wert von Feature Flags liegt in der schrittweisen Freigabe. Ein typischer Ablauf:
- QA-Team (User-IDs-Strategie): Das Feature ist nur für interne Tester sichtbar. Probleme werden erkannt, bevor externe Nutzende betroffen sind.
- Prozentualer Rollout (z. B. 10 %): Das Feature wird für einen definierten Anteil der Nutzenden aktiviert. Metriken und Fehlerraten lassen sich unter realen Bedingungen beobachten.
- Vollständige Freigabe: Erst wenn das Verhalten in der Produktion validiert ist, wird das Feature für alle aktiviert.
Tritt auf einer Stufe ein Problem auf, reicht ein Klick in der GitLab-Oberfläche, um das Feature zu deaktivieren – ohne Code-Änderung, ohne Pipeline.
Skalierung und Produktionsbetrieb
GitLab stellt für jedes Projekt eine Unleash-kompatible API bereit. Der Unleash-SDK pollt die Flag-Definitionen beim Start und danach in einem konfigurierbaren Intervall (im Demo-Projekt: 15 Sekunden). Die Auswertung erfolgt lokal aus dem Cache – kein Netzwerkaufruf pro Flag-Abfrage, kein Latenzeinfluss auf den Request.
Für kleinere Deployments ist das 15-Sekunden-Intervall gut geeignet. Bei Deployments mit vielen App-Instanzen von derselben IP-Adresse gilt: GitLab.com unterstützt bei diesem Intervall rund 125 Clients, bevor Rate-Limits greifen. Für größere Produktionsumgebungen empfiehlt sich ein vorgelagerter Unleash Proxy, der Anfragen mehrerer Instanzen bündelt.
Sicherheitsrelevante Aspekte
- Keine Credentials im Quellcode: Instance ID und alle Tokens gehören in Umgebungsvariablen, nicht in den Code.
- Instance ID ist read-only: Sie erlaubt ausschließlich das Abrufen von Flag-Zuständen, keine Änderungen. Trotzdem als Secret behandeln.
- Debug-Modus deaktiviert lassen: Flasks Debug-Modus ermöglicht Remote Code Execution – in der Produktion zwingend deaktiviert.
- Abhängigkeiten aktuell halten: Dependency Scanning in der CI/CD-Pipeline aktivieren, um Schwachstellen in gepinnten Versionen zu erkennen.
Schritt-für-Schritt: Integration in eine Python-Flask-App
Dieser Abschnitt gibt einen Überblick über die technische Integration. Die vollständige Implementierung – alle Schritte, der komplette Code und ein lauffähiges Demo-Projekt – ist im englischen Originalartikel beschrieben. Das Demo-Repository steht unter gitlab.com/omid-blogs/gitlab-feature-flags-demo zum Forken bereit.
SDK vs. GitLab REST API
Für eine App, die Flags bei jedem Request auswertet, ist der SDK die geeignete Wahl:
| REST API | Unleash SDK | |
|---|---|---|
| Authentifizierung | Personal Access Token mit Projektberechtigungen | Nur Instance ID – read-only, auf Flag-Zustand beschränkt |
| Flag-Auswertung | Netzwerkaufruf pro Abfrage | Lokal aus dem Cache |
| Latenz | Netzwerk-Round-Trip | Nahezu null (In-Memory) |
| Strategie-Unterstützung | Manuelle Auswertung erforderlich | Integriert: Prozentualer Rollout, User-ID-Targeting |
| Rate-Limits | GitLab.com API-Limits | Eine Poll-Verbindung pro App-Instanz |
Kernmuster der Integration
Die gesamte Integration besteht aus einer Abhängigkeit (UnleashClient), drei Umgebungsvariablen und einem Methodenaufruf.
SDK initialisieren:
url=UNLEASH_URL,
app_name=UNLEASH_APP_NAME,
instance_id=UNLEASH_INSTANCE_ID,
refresh_interval=15,
metrics_interval=60,
)
unleash_client.initialize_client() ```
**Flag abfragen:**
```python def is_flag_enabled(flag_name):
return unleash_client.is_enabled(flag_name)
is_enabled() wertet lokal aus dem Cache aus – kein Netzwerkaufruf, kein Latenzeinfluss auf den Request.
Nutzerkontext für gezieltes Targeting übergeben:
'new_layout',
context={'userId': current_user.id}
) ```
Der SDK übernimmt das konsistente Hashing für prozentuale Rollouts. Für die vollständige Einrichtung – Flags in GitLab anlegen, Unleash-Credentials abrufen, App lokal ausführen und Flags in Echtzeit umschalten – siehe den [englischen Originalartikel](https://about.gitlab.com/blog/getting-started-with-gitlab-feature-flags-in-python/).
### Ressourcen
* [Demo-Projekt auf GitLab](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo)
* [GitLab Feature-Flags-Dokumentation](https://docs.gitlab.com/operations/feature_flags/)
* [Unleash Python SDK auf GitHub](https://github.com/Unleash/unleash-python-sdk)
