Xüsusiyyət dondurması və kod dondurması tətbiq inkişafında: mahiyyəti, fərqləri və işi

Xüsusiyyət dondurması nədir?

Feature freeze — planlaşdırılmış buraxılışdan əvvəl kod bazasına yeni funksionallığın əlavə edilməsinə müvəqqəti qadağadır. Komanda xüsusiyyətləri merge etməyi dayandırır və səhvlərin düzəldilməsinə, optimallaşdırmaya və mövcud kodun cilalanmasına keçir. Proqramçılar yarımçıq xüsusiyyətləri yalnız səhv düzəlişləri çərçivəsində işləyib bitirir, əhatə dairəsini genişləndirmədən.

Xüsusiyyət dondurması buraxılışa çatmayan, lakin artıq qismən əsas budağa birləşdirilmiş yarımçıq xüsusiyyətlər (work-in-progress) problemini həll edir. Yeni xüsusiyyətləri daxil etməyə davam etsəniz, reqressiya riski artır: hər yeni inteqrasiya artıq hazır modulların yenidən test edilməsini tələb edir. Feature freeze buraxılışın əhatə dairəsini sabitləşdirərək onu hərəkət edən hədəfdən sabit funksionallıq dəstinə çevirir.

Vacib qeyd: feature freeze ≠ code freeze. Xüsusiyyət dondurması zamanı səhv düzəlişləri, refaktorinq, asılılıqların və sənədləşmənin yenilənməsi icazəlidir. Yalnız istifadəçiyə görünən yeni xüsusiyyətlər, yəni tətbiqin davranışını istifadəçi baxımından dəyişən hər hansı kod qadağandır. Code review yoxlaması: əgər PR yeni ekran, düymə və ya API metodu əlavə edirsə — dondurma ləğv edilənə qədər rədd edilir.

Kod dondurması nədir və xüsusiyyət dondurmasından nə fərqi var

Code freeze (kod dondurması) — daha sərt təcrübədir, burada koda hər hansı dəyişiklik tamamilə qadağandır. Hətta səhv düzəlişlərinə icazə verilmir, əgər onlar kritik deyilsə. Code freeze qısa müddətə (adətən 24-48 saat) tətbiq edilir və buraxılış biuldunun sabit kommitlər dəstindən yığılmasını təmin edir.

Xüsusiyyət dondurması ilə kod dondurması arasındakı fərq — nəzarət səviyyəsindədir. Xüsusiyyət dondurması əhatə dairəsini idarə edir: buraxılışa nə daxil olacaq. Kod dondurması keyfiyyəti idarə edir: buraxılışa bir gün qalmış yeni səhvin daxil olma riskini aradan qaldırır. Praktikada bir çox komandalar iki mərhələli modeldən istifadə edir: buraxılışa 1-2 həftə qalmış — feature freeze, 24-48 saat qalmış — code freeze. Code freeze xüsusilə mobil tətbiqlər üçün aktualdır, burada biuldu planlaşdırılmış buraxılış tarixindən bir neçə gün əvvəl mağazaya yükləmək lazımdır.

Code freeze-dən istisna — kritik zəifliklərin (balı 9+ olan CVE) təhlükəsizlik düzəlişləridir. Belə dəyişikliklər məcburi sürətləndirilmiş code review və komanda xəbərdarlığı ilə təcili prosesdən keçir. Bütün digər dəyişikliklər növbəti buraxılış dövrünə qədər təxirə salınır.

Feature freeze vs code freeze: müqayisə

Xüsusiyyət dondurması ilə kod dondurması arasında seçim komandanın yetkinliyindən və buraxılış tezliyindən asılıdır. CI/CD və feature flags olan komandalar yalnız 24 saatlıq code freeze ilə keçinə bilər, aylıq buraxılışları olan komandalar isə daha çox hər iki dondurmanı ardıcıl olaraq tətbiq edir.

Dondurma növləri: tam, qismən və BAU-freeze

Tam xüsusiyyət dondurması və kod dondurmasından başqa daha çevik variantlar da mövcuddur. Partial feature freeze (qismən dondurma) yeni funksionallığı yalnız müəyyən modullarda bloklayır — məsələn, ödəniş modulunda və ya avtorizasiya modulunda, qalan komponentləri dəyişikliklər üçün açıq qoyaraq.

BAU-freeze (business as usual freeze) — kompromis variantdır, burada yalnız müəyyən həddi (məsələn, 500 sətir kod) aşan böyük xüsusiyyətlər qadağandır. Kiçik təkmilləşdirmələr, UI düzəlişləri və səhv düzəlişləri daxil edilməyə davam edir. BAU-freeze continuous delivery layihələri üçün əlverişlidir, burada inkişafın bir həftə tam dayandırılması iqtisadi cəhətdən sərfəli deyil.

Həmçinin deployment freeze (yerləşdirmə dondurması) anlayışı var — istehsalata yerləşdirmələrin tam dayandırılması, bayram mövsümü (Milad tətili, Black Friday) üçün xarakterikdir. Bu dövrdə hətta hotfixlər də bloklanır, əgər onlar təhlükəsizliklə bağlı deyilsə. Deployment freeze adətən 1-2 həftə davam edir və şirkət səviyyəsində razılaşdırılır.

Dondurma nə zaman tətbiq edilməli və nə qədər davam edir

Xüsusiyyət dondurmasının tətbiqi üçün optimal vaxt — code complete-dən sonra, bütün planlaşdırılmış xüsusiyyətlər merge edildikdə və QA-dan keçdikdə. Konkret müddət buraxılış dövründən asılıdır: iki həftəlik sprint üçün xüsusiyyət dondurması buraxılış tarixindən 3-4 gün əvvəl, aylıq buraxılış üçün — 7-10 gün əvvəl tətbiq edilir. Code freeze buraxılış biuldunun planlaşdırılmış yığılma vaxtından 24-48 saat əvvəl tətbiq edilir.

Dondurmanın müddəti kodun sabitləşdirilməsi üçün minimal kifayət olmalıdır. Çox uzun dondurma (2 həftədən çox) komandanı motivasiyasızlaşdırır və merge edilməmiş xüsusiyyətlərin yığılmasına səbəb olur, hər biri dondurma ləğv edildikdən sonra konflikt riskini artırır. Çox qısa dondurma (xüsusiyyət dondurması üçün 24 saatdan az) tam test və düzəlişlər üçün vaxt vermir.

Tövsiyə olunan təcrübə — dondurmanı təqvim tarixinə görə deyil, kod bazasının vəziyyətinə görə təyin etməkdir. Xüsusiyyət dondurması buraxılışda açıq səhvlərin sayı həddi (məsələn, 10 kritik səhv) aşdıqda tətbiq edilir. Code freeze — biuld smoke testləri və reqressiya dəstini uğurla keçdikdə. Time-based freeze (sabit tarix) tənzimlənən sənayelər (fintech, medtech) üçün standart olaraq qalır, burada buraxılış tarixi tənzimləyici tərəfindən təsdiqlənir.

CI/CD və Git vasitəsilə dondurmaların avtomatlaşdırılması

Dondurmaların əl ilə idarə edilməsi — səhv mənbəyidir: proqramçı təsadüfən dondurmanın ləğvini gözləməli olan PR-i merge edə bilər. Avtomatlaşdırma problemi Git branch protection qaydaları və CI/CD pipeline-ları vasitəsilə həll edir. Git provayderində (GitHub, GitLab, Bitbucket) xüsusi tag və ya release manager-in icazəsi olmadan buraxılış budağına mergeləri bloklayan qaydalar konfiqurasiya edilir.

CI/CD pipeline biuld yığılmasından əvvəl dondurma statusunu yoxlayır. Jenkins, GitLab CI və ya GitHub Actions-da dondurma cədvəli olan konfiqurasiya faylını oxuyan və cari tarix dondurma dövrünə düşərsə biuldları rədd edən addım əlavə olunur. Alternativ — istehsalata yerləşdirməni bloklayan admin paneldəki feature flag.

# .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 "Xüsusiyyət dondurması aktivdir. PR bloklanıb." && exit 1

Nümunə freeze-check.js skripti repo kökündən dondurma cədvəli olan JSON-u oxuyur. Əgər cari tarix müəyyən budaq üçün start_date və end_date arasındakı intervala düşərsə — pipeline dondurma statusu haqqında mesajla uğursuz olur. Git branch protection ikinci maneə əlavə edir: pipeline işləməsə belə, qayda icazəsiz PR-in merge edilməsinə imkan vermir.

Dondurmaların tətbiqində tipik səhvlər

Birinci səhv — aydın ləğv etmə meyarı olmayan dondurma. Komanda kodu dondurur, lakin dondurmanı ləğv etmək üçün hansı şərtlərin yerinə yetirilməli olduğunu müəyyən etmir: sıfır kritik səhv, uğurla keçilmiş reqressiya dəsti, product menecerinin təsdiqi. Meyarlar olmadan dondurma həftələrlə uzana bilər. Definition of done dondurma üçün sənədləşdirilməli və hər proqramçıya məlum olmalıdır.

İkinci səhv — dondurmadan çox sayda istisna. Hər bir istisna („bu PR xüsusiyyət deyil, texniki borcdur“) dondurmanın sərhədlərini bulandırır. Əgər istisnalar adi PR axınının 20%-dən çox olarsa — dondurma işləmir. Komanda sadəcə blokadanı keçmək üçün xüsusiyyətlərin adını səhv düzəlişləri olaraq dəyişir.

Üçüncü səhv — release candidate-lərə məhəl qoymamaq. Əgər komanda release candidate biuldları yığmır və code freeze-dən sonra dərhal istehsalata yerləşdirirsə, dondurmanın mənası itir: səhvlər yalnız istifadəçilərdə aşkar edilir. Release candidate code freeze-dən əvvəl yığılmalı, QA və steycinqdə test edilməli və yalnız keyfiyyət təsdiqləndikdən sonra code freeze tətbiq edilməlidir.

Dördüncü səhv — əl ilə idarədə insan faktoru. Proqramçı merge etməzdən əvvəl dondurma statusunu yoxlamağı unuda bilər, release manager — bildirişi qaçıra bilər. Yeganə etibarlı həll — Git provayderi və ya CI/CD səviyyəsində insan səhvini aradan qaldıran avtomatik blokadadır.