Feature freeze och code freeze i apputveckling: innebörd, skillnader och funktion

Vad är feature freeze?

Feature freeze — ett tillfälligt förbud mot att lägga till ny funktionalitet i kodbasen, infört före en planerad release. Teamet slutar merga funktioner och övergår till att fixa buggar, optimera och polera befintlig kod. Utvecklare slutför ofullständiga funktioner endast inom ramen för buggfixar, utan att utöka omfattningen.

Feature freeze löser problemet med ofullständiga funktioner (work-in-progress) som inte hinns med till releasen men redan delvis har mergats in i huvudgrenen. Om nya funktioner fortsätter att läggas till ökar risken för regression: varje ny integration kräver omtestning av redan färdiga moduler. Feature freeze fastställer releaseomfattningen och förvandlar den från ett rörligt mål till en stabil uppsättning funktionaliteter.

Viktig förtydligande: feature freeze ≠ code freeze. Vid feature freeze är buggfixar, refactoring, uppdatering av beroenden och dokumentation tillåtna. Endast nya user-facing-funktioner är förbjudna, det vill säga all kod som ändrar appens beteende ur användarens perspektiv. Kontroll vid code review: om ett PR lägger till en ny skärm, knapp eller API-metod — avvisas det tills freeze hävs.

Vad är code freeze och hur skiljer det sig från feature freeze

Code freeze — en strängare metod där alla ändringar i koden är helt förbjudna. Inte ens buggfixar är tillåtna om de inte är kritiska. Code freeze införs under en kort period (vanligtvis 24-48 timmar) och garanterar att release-builden är sammansatt från en fast uppsättning commits.

Skillnaden mellan feature freeze och code freeze ligger i kontrollnivån. Feature freeze hanterar omfattningen: vad som exakt ingår i releasen. Code freeze hanterar kvaliteten: risken för att en ny bugg introduceras en dag före releasen utesluts. I praktiken använder många team en tvåstegsmodell: 1-2 veckor före releasen — feature freeze, 24-48 timmar — code freeze. Code freeze är särskilt viktigt för mobila appar, där bygget måste laddas upp till butiken flera dagar före det planerade releasedatumet.

Undantag från code freeze — säkerhetsfixar för kritiska sårbarheter (CVE med poäng 9+). Sådana ändringar går igenom en nödprocess med snabb code review och teammeddelande. Alla andra ändringar skjuts upp till nästa releasecykel.

Feature freeze vs code freeze: jämförelse

Valet mellan feature freeze och code freeze beror på teamets mognad och releasefrekvens. Team med CI/CD och feature flags kan begränsa sig till endast code freeze på 24 timmar, medan team med månadsreleaser vanligtvis använder båda frysningarna i följd.

Typer av freeze: fullständig, partiell och BAU-freeze

Förutom fullständig feature freeze och code freeze finns det mer flexibla varianter. Partial feature freeze (partiell freeze) blockerar ny funktionalitet endast i vissa moduler — till exempel i betalningsmodulen eller autentiseringsmodulen, medan andra komponenter förblir öppna för ändringar.

BAU-freeze (business as usual freeze) — en kompromissvariant där endast stora funktioner med ändringsvolym över en viss tröskel (t.ex. 500 rader kod) är förbjudna. Små förbättringar, UI-justeringar och buggfixar fortsätter. BAU-freeze är lämplig för projekt med continuous delivery, där ett fullständigt utvecklingsstopp på en vecka är ekonomiskt ofördelaktigt.

Det finns också begreppet deployment freeze — ett fullständigt stopp för deployar till produktion, typiskt för semesterperioden (julhelger, Black Friday). Under denna period blockeras även hotfixar om de inte rör säkerhet. Deployment freeze varar vanligtvis 1-2 veckor och samordnas på företagsnivå.

När ska freeze införas och hur länge varar det

Den optimala tidpunkten för att införa feature freeze — efter code complete, när alla planerade funktioner har mergats och genomgår QA. Den exakta tidsfristen beror på releasecykeln: för en tvåveckors sprint införs feature freeze 3-4 dagar före releasedatumet, för en månadsrelease — 7-10 dagar i förväg. Code freeze införs 24-48 timmar före den planerade tiden för byggandet av release-builden.

Freezens varaktighet bör vara minimalt tillräcklig för att stabilisera koden. En för lång freeze (mer än 2 veckor) demotiverar teamet och skapar en ansamling av icke-mergade funktioner, som var och en efter att freeze hävs ökar risken för konflikter. En för kort freeze (mindre än 24 timmar för feature freeze) ger inte tillräckligt med tid för grundlig testning och korrigeringar.

Rekommenderad praxis — fastställ freeze inte baserat på kalenderdatum, utan baserat på kodbasens tillstånd. Feature freeze införs när antalet öppna buggar för releasen överstiger en tröskel (t.ex. 10 kritiska buggar). Code freeze — när bygget framgångsrikt passerar smoke tests och regression suite. Time-based freeze (fast datum) förblir standard för reglerade industrier (fintech, medtech), där releasedatumet har godkänts av tillsynsmyndigheten.

Automatisering av freeze via CI/CD och Git

Manuell kontroll av freeze är en felkälla: en utvecklare kan av misstag merga ett PR som borde vänta på att freeze hävs. Automatisering löser problemet via Git branch protection-regler och CI/CD-pipelines. Hos Git-leverantören (GitHub, GitLab, Bitbucket) sätts regler som blockerar merges till releasegrenen utan särskild tagg eller godkännande från release managern.

CI/CD-pipeline kontrollerar freezestatusen före byggandet. I Jenkins, GitLab CI eller GitHub Actions läggs ett steg till som läser en konfigurationsfil med frysningsschemat och avvisar byggen om aktuellt datum faller inom frysperioden. Alternativ — en feature flag i adminpanelen som blockerar deploy till produktion.

# .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 är aktiv. PR blockerat." && exit 1

Exempelskriptet freeze-check.js läser JSON med frysningsschemat från rotkatalogen i databasen. Om aktuellt datum ligger inom intervallet mellan start_date och end_date för den angivna grenen — misslyckas pipelinen med ett meddelande om freezestatusen. Git branch protection lägger till en andra barriär: även om pipelinen inte fungerar, tillåter regeln inte att PR mergas utan godkännande.

Typiska misstag vid införande av freeze

Första misstaget — freeze utan tydliga kriterier för att häva den. Teamet fryser koden men bestämmer inte vilka villkor som måste uppfyllas för upptining: noll kritiska buggar, godkänd regression suite, godkännande från produktchefen. Utan kriterier kan en freeze pågå i veckor. Definition of done för freeze måste vara dokumenterad och känd för varje utvecklare.

Andra misstaget — för många undantag från freeze. Varje exception ("detta PR är inte en funktion, utan teknisk skuld") suddar ut freezens gräns. Om exceptions överstiger 20% av det normala PR-flödet — fungerar inte freeze. Teamet döper helt enkelt om funktioner till buggfixar för att kringgå blockeringen.

Tredje misstaget — att ignorera release candidates. Om teamet inte bygger release candidate-byggen och omedelbart deployar till produktion efter code freeze, förloras meningen med freeze: buggar upptäcks av användarna. Release candidate bör byggas före code freeze, testas av QA och på staging, och först efter kvalitetsbekräftelse införs code freeze.

Fjärde misstaget — mänsklig faktor vid manuell kontroll. En utvecklare kan glömma att kontrollera freezestatusen före merge, en release manager kan missa notifieringen. Den enda pålitliga lösningen — automatisk blockering på Git provider- eller CI/CD-nivå som utesluter mänskliga fel.