Uygulama geliştirmede feature freeze ve code freeze: özü, farkları ve rolü

Feature freeze nedir?

Feature freeze, planlanan bir yayından önce kod tabanına yeni işlevsellik eklenmesine geçici olarak yasak getirilmesidir. Takım özellikleri birleştirmeyi durdurur ve hata düzeltme, optimizasyon ve mevcut kodu iyileştirmeye odaklanır. Geliştiriciler tamamlanmamış özellikleri yalnızca hata düzeltmeleri kapsamında tamamlar, kapsamı genişletmez.

Feature freeze, yayına yetişemeyen ancak ana dala kısmen birleştirilmiş olan devam eden özellikler sorununu çözer. Yeni özellikler birleştirilmeye devam ederse, regresyon riski artar: her yeni entegrasyon, zaten tamamlanmış modüllerin yeniden test edilmesini gerektirir. Feature freeze yayın kapsamını sabitler ve onu hareketli bir hedeften istikrarlı bir işlevsellik setine dönüştürür.

Önemli bir açıklama: feature freeze ≠ code freeze. Feature freeze sırasında hata düzeltmeleri, yeniden düzenleme, bağımlılık güncellemeleri ve dokümantasyona izin verilir. Yalnızca kullanıcıya yönelik yeni özellikler yasaktır, yani kullanıcının bakış açısından uygulamanın davranışını değiştiren herhangi bir kod. Kod inceleme kontrolü: Bir PR yeni bir ekran, düğme veya API yöntemi ekliyorsa, dondurma kaldırılana kadar reddedilir.

Code freeze nedir ve feature freeze'den farkı

Code freeze, kod üzerindeki tüm değişikliklerin tamamen yasaklandığı daha katı bir uygulamadır. Kritik olmadıkça hata düzeltmelerine bile izin verilmez. Code freeze kısa bir süre için (genellikle 24-48 saat) uygulanır ve yayın yapısının sabit bir commit kümesinden oluşturulmasını garanti eder.

Feature freeze ve code freeze arasındaki fark, kontrol seviyesindedir. Feature freeze kapsamı yönetir: yayına tam olarak neyin dahil edileceğini belirler. Code freeze kaliteyi yönetir: yayından bir gün önce yeni bir hata eklenmesi riskini ortadan kaldırır. Pratikte birçok takım iki aşamalı bir model kullanır: yayından 1-2 hafta önce feature freeze, 24-48 saat önce code freeze. Code freeze, yapının planlanan yayın tarihinden birkaç gün önce mağazaya yüklenmesi gereken mobil uygulamalar için özellikle önemlidir.

Code freeze'in istisnası, kritik güvenlik açıkları (CVE puanı 9+) için yapılan güvenlik düzeltmeleridir. Bu tür değişiklikler, zorunlu hızlı kod incelemesi ve takım bildirimi ile acil durum sürecinden geçer. Diğer tüm değişiklikler bir sonraki yayın döngüsüne ertelenir.

Feature freeze vs code freeze: karşılaştırma

Feature freeze ve code freeze arasındaki seçim, takımın olgunluğuna ve yayın sıklığına bağlıdır. CI/CD ve özellik bayraklarına sahip takımlar yalnızca 24 saatlik bir code freeze'e ihtiyaç duyabilirken, aylık yayın yapan takımlar her iki dondurmayı da sırayla kullanma eğilimindedir.

Dondurma türleri: tam, kısmi ve BAU dondurma

Tam feature freeze ve code freeze dışında daha esnek seçenekler de vardır. Kısmi feature freeze, yeni işlevselliği yalnızca belirli modüllerde (örneğin, ödeme modülü veya yetkilendirme modülü) engeller, diğer bileşenleri değişikliklere açık bırakır.

BAU dondurma (business as usual freeze) bir uzlaşma seçeneğidir ve yalnızca değişiklik hacmi belirli bir eşiği (örneğin 500 kod satırı) aşan büyük özellikler yasaklanır. Küçük iyileştirmeler, UI ayarlamaları ve hata düzeltmeleri birleştirilmeye devam eder. BAU dondurma, bir haftalık tam geliştirme durdurmanın ekonomik olarak uygun olmadığı sürekli teslimat projeleri için uygundur.

Ayrıca dağıtım dondurma (deployment freeze) kavramı da vardır — üretime yapılan tüm dağıtımların tamamen durdurulması, tatil sezonu (Noel tatili, Black Friday) için tipiktir. Bu dönemde, güvenlikle ilgili olmadıkça sıcak düzeltmeler bile engellenir. Dağıtım dondurma genellikle 1-2 hafta sürer ve şirket düzeyinde koordine edilir.

Dondurma ne zaman uygulanır ve ne kadar sürer

Feature freeze'i uygulamak için en uygun zaman, kod tamamlandıktan sonra, tüm planlanan özellikler birleştirilmiş ve QA sürecinden geçiyorkendir. Kesin zamanlama yayın döngüsüne bağlıdır: iki haftalık bir sprint için feature freeze, yayın tarihinden 3-4 gün önce uygulanır; aylık yayın için 7-10 gün önce. Code freeze, planlanan yayın yapısı oluşturma zamanından 24-48 saat önce uygulanır.

Dondurma süresi, kodu stabilize etmek için yeterli olan minimum süre olmalıdır. Çok uzun bir dondurma (2 haftadan fazla) takımın motivasyonunu düşürür ve birleştirilmemiş özelliklerin birikmesine neden olur; bunların her biri dondurma kaldırıldıktan sonra çatışma riskini artırır. Çok kısa bir dondurma (feature freeze için 24 saatten az) kapsamlı test ve düzeltmeler için yeterli zaman sağlamaz.

Önerilen uygulama, dondurmayı takvim tarihine göre değil, kod tabanı durumuna göre ayarlamaktır. Feature freeze, yayın için açık hata sayısı bir eşiği (örneğin 10 kritik hata) aştığında uygulanır. Code freeze — yapı, smoke testlerini ve regresyon paketini başarıyla geçtiğinde uygulanır. Zamana dayalı dondurma (sabit tarih), yayın tarihinin bir düzenleyici kurum tarafından onaylandığı düzenlemeye tabi sektörlerde (fintek, medtek) standart olmaya devam etmektedir.

CI/CD ve Git ile dondurmaların otomasyonu

Manuel dondurma kontrolü hata kaynağıdır: bir geliştirici yanlışlıkla dondurma kaldırılana kadar beklemesi gereken bir PR'yi birleştirebilir. Otomasyon, Git dal koruma kuralları ve CI/CD boru hatları aracılığıyla bunu çözer. Git sağlayıcısında (GitHub, GitLab, Bitbucket), özel bir etiket veya yayın yöneticisinin onayı olmadan yayın dalına birleştirmeleri engelleyen kurallar yapılandırılır.

CI/CD boru hattı, yapıyı oluşturmadan önce dondurma durumunu kontrol eder. Jenkins, GitLab CI veya GitHub Actions'da, dondurma takvimi içeren bir yapılandırma dosyasını okuyan ve geçerli tarih dondurma dönemine denk gelirse yapıları reddeden bir adım eklenir. Bir alternatif, yönetici panelinde üretime dağıtımı engelleyen bir özellik bayrağıdır.

# .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

Örnek freeze-check.js betiği, depo kökünden dondurma takvimi içeren bir JSON okur. Geçerli tarih belirtilen dal için start_date ve end_date arasındaki aralığa denk gelirse, boru hattı bir dondurma durum mesajıyla başarısız olur. Git dal koruması ikinci bir engel ekler: boru hattı tetiklenmemiş olsa bile, kural onay olmadan PR'nin birleştirilmesine izin vermez.

Dondurma uygularken yaygın hatalar

İlk hata, net kaldırma kriterleri olmadan dondurma yapmaktır. Takım kodu dondurur ancak çözmek için hangi koşulların karşılanması gerektiğini tanımlamaz: sıfır kritik hata, regresyon paketini geçme, ürün yöneticisi onayı. Kriterler olmadan dondurma haftalarca sürebilir. Dondurma için tamamlama tanımı belgelenmeli ve her geliştirici tarafından bilinmelidir.

İkinci hata, dondurmaya çok fazla istisna yapmaktır. Her istisna (“bu PR bir özellik değil, teknik borçtur”) dondurma sınırını bulanıklaştırır. İstisnalar normal PR akışının %20'sini aşarsa, dondurma çalışmaz. Takım, engeli aşmak için özellikleri basitçe hata düzeltmeleri olarak yeniden adlandırır.

Üçüncü hata, yayın adaylarını göz ardı etmektir. Takım yayın adayı yapıları oluşturmaz ve code freeze'den sonra doğrudan üretime dağıtırsa, dondurmanın amacı kaybolur: hatalar kullanıcılar tarafından keşfedilir. Yayın adayı code freeze'den önce oluşturulmalı, QA ve test ortamında test edilmeli ve yalnızca kalite onayından sonra code freeze uygulanmalıdır.

Dördüncü hata, manuel kontrolde insan faktörüdür. Bir geliştirici birleştirmeden önce dondurma durumunu kontrol etmeyi unutabilir, bir yayın yöneticisi bildirimi kaçırabilir. Tek güvenilir çözüm, Git sağlayıcısı veya CI/CD düzeyinde insan hatasını ortadan kaldıran otomatik engellemedir.