Feature Freeze und Code Freeze in der App-Entwicklung: Wesen, Unterschiede und Rolle

Was ist ein Feature Freeze?

Feature Freeze ist ein vorübergehendes Verbot, neue Funktionalitäten zur Codebasis hinzuzufügen, das vor einem geplanten Release eingeführt wird. Das Team hört auf, Features zu mergen, und konzentriert sich auf Fehlerbehebungen, Optimierungen und die Verbesserung des vorhandenen Codes. Entwickler schließen unvollständige Funktionen nur im Rahmen von Bugfixes ab, ohne den Umfang zu erweitern.

Der Feature Freeze löst das Problem von Work-in-Progress-Funktionen, die es nicht rechtzeitig zum Release schaffen, aber bereits teilweise in den Hauptzweig gemergt wurden. Wenn weiterhin neue Funktionen gemergt werden, steigt das Risiko von Regressionen: Jede neue Integration erfordert erneutes Testen bereits fertiger Module. Feature Freeze fixiert den Release-Umfang und verwandelt ihn von einem beweglichen Ziel in einen stabilen Funktionsumfang.

Eine wichtige Klarstellung: Feature Freeze ≠ Code Freeze. Während eines Feature Freezes sind Bugfixes, Refactoring, Abhängigkeitsaktualisierungen und Dokumentation erlaubt. Verboten sind nur neue benutzersichtbare Funktionen, also jeglicher Code, der das Verhalten der Anwendung aus Benutzersicht ändert. Code-Review-Prüfung: Wenn ein PR einen neuen Bildschirm, Button oder API-Methode hinzufügt, wird er abgelehnt, bis der Freeze aufgehoben wird.

Was ist ein Code Freeze und wie unterscheidet er sich vom Feature Freeze

Code Freeze ist eine strengere Praxis, bei der alle Code-Änderungen vollständig verboten sind. Selbst Fehlerbehebungen sind nicht erlaubt, es sei denn, sie sind kritisch. Der Code Freeze wird für einen kurzen Zeitraum (normalerweise 24-48 Stunden) eingeführt und garantiert, dass der Release-Build aus einem festgelegten Satz von Commits erstellt wird.

Der Unterschied zwischen Feature Freeze und Code Freeze liegt in der Kontrollebene. Der Feature Freeze verwaltet den Umfang: Was genau in den Release aufgenommen wird. Der Code Freeze verwaltet die Qualität: Er eliminiert das Risiko, einen Tag vor dem Release einen neuen Bug einzuführen. In der Praxis verwenden viele Teams ein zweistufiges Modell: 1-2 Wochen vor dem Release einen Feature Freeze, 24-48 Stunden vorher einen Code Freeze. Code Freeze ist besonders relevant für mobile Apps, bei denen der Build mehrere Tage vor dem geplanten Release-Datum in den Store hochgeladen werden muss.

Die Ausnahme vom Code Freeze sind Sicherheitskorrekturen für kritische Schwachstellen (CVE mit Bewertung 9+). Solche Änderungen durchlaufen einen Notfallprozess mit obligatorischem Fast-Track-Code-Review und Team-Benachrichtigung. Alle anderen Änderungen werden auf den nächsten Release-Zyklus verschoben.

Feature Freeze vs Code Freeze: Vergleich

Die Wahl zwischen Feature Freeze und Code Freeze hängt von der Reife des Teams und der Release-Häufigkeit ab. Teams mit CI/CD und Feature Flags kommen möglicherweise mit einem 24-stündigen Code Freeze aus, während Teams mit monatlichen Releases häufiger beide Freezes nacheinander verwenden.

Arten von Freezes: vollständig, teilweise und BAU-Freeze

Neben dem vollständigen Feature Freeze und Code Freeze gibt es flexiblere Optionen. Partial Feature Freeze (teilweiser Freeze) blockiert neue Funktionalitäten nur in bestimmten Modulen — zum Beispiel im Zahlungsmodul oder im Authentifizierungsmodul, während andere Komponenten für Änderungen offen bleiben.

BAU-Freeze (Business as Usual Freeze) ist eine Kompromisslösung, bei der nur große Funktionen mit einem Änderungsumfang über einer bestimmten Schwelle (z. B. 500 Codezeilen) verboten sind. Kleine Verbesserungen, UI-Anpassungen und Fehlerbehebungen werden weiterhin gemergt. BAU-Freeze ist praktisch für Projekte mit kontinuierlicher Lieferung, bei denen ein vollständiger Entwicklungsstopp für eine Woche wirtschaftlich nicht sinnvoll ist.

Es gibt auch das Konzept des Deployment Freeze — ein vollständiger Stopp von Deployments in die Produktion, typisch für die Ferienzeit (Weihnachtsferien, Black Friday). In diesem Zeitraum werden selbst Hotfixes blockiert, es sei denn, sie betreffen die Sicherheit. Ein Deployment Freeze dauert normalerweise 1-2 Wochen und wird auf Unternehmensebene koordiniert.

Wann ein Freeze eingeführt wird und wie lange er dauert

Der optimale Zeitpunkt für die Einführung eines Feature Freeze ist nach dem Code Complete, wenn alle geplanten Funktionen gemergt sind und sich im QA befinden. Der genaue Zeitpunkt hängt vom Release-Zyklus ab: Bei einem zweiwöchigen Sprint wird der Feature Freeze 3-4 Tage vor dem Release-Datum eingeführt, bei einem monatlichen Release 7-10 Tage vorher. Code Freeze wird 24-48 Stunden vor der geplanten Erstellungszeit des Release-Builds eingeführt.

Die Dauer des Freezes sollte das Minimum sein, das zur Stabilisierung des Codes ausreicht. Ein zu langer Freeze (mehr als 2 Wochen) demotiviert das Team und führt zu einer Ansammlung nicht gemergter Funktionen, von denen jede nach Aufhebung des Freezes das Konfliktrisiko erhöht. Ein zu kurzer Freeze (weniger als 24 Stunden für einen Feature Freeze) lässt nicht genügend Zeit für gründliche Tests und Korrekturen.

Die empfohlene Praxis besteht darin, den Freeze nicht nach Kalenderdatum, sondern nach dem Zustand der Codebasis zu setzen. Ein Feature Freeze wird eingeführt, wenn die Anzahl der offenen Bugs für den Release einen Schwellenwert überschreitet (z. B. 10 kritische Bugs). Code Freeze — wenn der Build erfolgreich Smoke-Tests und die Regressionssuite besteht. Time-based Freeze (festes Datum) bleibt der Standard für regulierte Branchen (Fintech, Medtech), in denen das Release-Datum von einer Aufsichtsbehörde genehmigt wird.

Automatisierung von Freezes via CI/CD und Git

Manuelle Freeze-Kontrolle ist eine Fehlerquelle: Ein Entwickler könnte versehentlich einen PR mergen, der bis zur Aufhebung des Freezes warten sollte. Die Automatisierung löst dies durch Git-Branch-Schutzregeln und CI/CD-Pipelines. Im Git-Anbieter (GitHub, GitLab, Bitbucket) werden Regeln konfiguriert, die Merges in den Release-Branch ohne spezielles Tag oder Genehmigung des Release-Managers blockieren.

CI/CD-Pipeline prüft den Freeze-Status vor dem Erstellen des Builds. In Jenkins, GitLab CI oder GitHub Actions wird ein Schritt hinzugefügt, der eine Konfigurationsdatei mit dem Freeze-Zeitplan liest und Builds ablehnt, wenn das aktuelle Datum in den Freeze-Zeitraum fällt. Eine Alternative ist ein Feature-Flag im Admin-Panel, das das Deployment in die Produktion blockiert.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

Das Beispiel-Skript freeze-check.js liest ein JSON mit dem Freeze-Zeitplan aus dem Repository-Stammverzeichnis. Wenn das aktuelle Datum in das Intervall zwischen start_date und end_date für den angegebenen Branch fällt, schlägt die Pipeline mit einer Freeze-Statusmeldung fehl. Git-Branch-Schutz fügt eine zweite Barriere hinzu: Selbst wenn die Pipeline nicht ausgelöst wurde, erlaubt die Regel das Mergen des PRs ohne Genehmigung nicht.

Häufige Fehler bei der Einführung von Freezes

Der erste Fehler ist ein Freeze ohne klare Aufhebungskriterien. Das Team friert den Code ein, definiert aber nicht, welche Bedingungen für die Aufhebung erfüllt sein müssen: null kritische Bugs, bestandene Regressionssuite, Genehmigung des Produktmanagers. Ohne Kriterien kann sich der Freeze über Wochen hinziehen. Die Definition of Done für den Freeze sollte dokumentiert und jedem Entwickler bekannt sein.

Der zweite Fehler sind zu viele Ausnahmen vom Freeze. Jede Ausnahme („Dieser PR ist kein Feature, sondern technische Schuld“) verwischt die Grenze des Freezes. Wenn Ausnahmen 20 % des normalen PR-Flusses überschreiten, funktioniert der Freeze nicht. Das Team benennt Funktionen einfach in Fehlerbehebungen um, um die Blockade zu umgehen.

Der dritte Fehler ist das Ignorieren von Release Candidates. Wenn das Team keine Release-Candidate-Builds erstellt und direkt nach dem Code Freeze in die Produktion deployed, geht der Sinn des Freezes verloren: Bugs werden von Benutzern entdeckt. Der Release Candidate sollte vor dem Code Freeze erstellt, von QA und auf Staging getestet werden, und erst nach Bestätigung der Qualität wird der Code Freeze eingeführt.

Der vierte Fehler ist der menschliche Faktor bei der manuellen Kontrolle. Ein Entwickler könnte vergessen, den Freeze-Status vor dem Merge zu überprüfen, ein Release-Manager könnte eine Benachrichtigung übersehen. Die einzig zuverlässige Lösung ist die automatische Blockierung auf Ebene des Git-Anbieters oder der CI/CD, die menschliche Fehler ausschließt.