Uygulama geliştirmede hotfix: Özü, mekanizması ve nasıl uygulanacağı

Hotfix nedir ve ne zaman gereklidir?

Hotfix (acil düzeltme), kritik bir sorunu gidermek için sıra dışı yayınlanan uygulamanın üretim sürümü için bir yamadır. Hotfix, kullanıcılara günler içinde değil, saatler içinde ulaştırılır ve yalnızca uygulamanın kullanılamadığı, veri kaybettiği veya kullanıcı güvenliğini tehlikeye attığı durumlar için tasarlanmıştır.

Hotfix için tipik senaryolar: belirli cihazlarda başlatma sırasında çökme (son sürümden sonra gerileme), hatalı yetkilendirme nedeniyle kişisel veri sızıntısı, bozuk ödeme entegrasyonu (gelir kaybı), GDPR/CCPA uyum ihlalleri. Tüm bu durumlar olay sınıflandırmasında P0 veya P1 ciddiyetine sahiptir. Planlı görevler — optimizasyon, yeniden düzenleme, yeni ekranlar — asla hotfix yoluyla yapılmaz.

Önemli bir kural: hotfix minimum sayıda değişiklik içerir (1–2 dosya, 10–20 satır kod). Diff ne kadar küçük olursa, yeni bir hata ekleme riski o kadar düşük olur. Sorunu düzeltmek için mimariyi değiştirmek veya yeni bir modül eklemek gerekiyorsa — bu bir hotfix değil, tam kod incelemesi ve QA gerektiren acil bir sürümdür.

Hotfix'in normal sürümden farkı

Hotfix ile planlı sürüm arasındaki temel farklar hız, değişiklik kapsamı ve test seviyesidir. Planlı bir sürüm onlarca özellik içerebilir, tam bir QA döngüsünden (gerileme + entegrasyon + UI testleri) geçebilir ve kod dondurmadan dağıtıma kadar 1–2 hafta sürebilir. Hotfix bir veya iki düzeltme içerir, hızlandırılmış incelemeden (3 yerine 2 onay) ve minimum smoke testinden geçer.

Git süreci açısından, hotfix bir sürüm etiketinden oluşturulur, develop dalından değil. Bu, hotfix'e yalnızca sorunu gidermek için gerekli değişikliklerin dahil edilmesini, develop'taki bitmemiş özelliklerin yanlışlıkla alınmamasını sağlar. Dağıtımdan sonra hotfix, main ve develop'a geri birleştirilir (cherry-pick veya merge yoluyla).

Planlı sürüm ve hotfix karşılaştırması

Önemli: her acil görev hotfix değildir. Bir yönetici “acilen bir buton eklememiz gerekiyor” derse — bu hotfix değil, öncelik değişikliğidir. Gerçek bir hotfix, iş aciliyetiyle değil, kullanıcı için ciddiyetle belirlenir. Kriter: uygulama çökmüyor ve veriler sızmıyorsa — görev planlı sürümü bekler.

Hotfix süreci: keşiften dağıtıma

Kritik bir sorun keşfedildiğinde ilk adım triyajdır — hızlı bir ciddiyet değerlendirmesi. Nöbetçi mühendis hatayı onaylar, günlükleri ve çökme raporlarını kontrol eder ve sorunun son sürümden kaynaklanan bir gerileme mi yoksa uzun süreli bir hata mı olduğunu belirler. Ciddiyet P0 ise — hotfix pipeline'ı tetiklenir. Triyaj aşaması 15 dakikadan fazla sürmemelidir.

İkinci adım — en son sürüm etiketinden bir dal oluşturmak (v2.5.0 → hotfix/v2.5.1). Geliştirici minimum düzeltmeyi yapar, mesajda HOTFIX önekiyle commit yapar, gönderir ve [HOTFIX] etiketiyle PR açar. Fast-track kod incelemesi: CODEOWNERS aracılığıyla iki incelemci otomatik olarak atanır, inceleme süresi en fazla 30 dakikadır. 20 dakika içinde inceleme olmazsa — incelemci atlanır ve bir sonraki atanır.

Üçüncü adım — CI/CD aracılığıyla derleme ve dağıtım. Hotfix pipeline'ı normalden farklıdır: uzun entegrasyon testleri (saatler süren) atlanır, yalnızca smoke paketi çalıştırılır (10–15 kritik senaryo, 5–10 dakika). Dağıtımdan sonra: çökme oranı, hata oranı, API gecikmesi — 30 dakika boyunca izlenir. Hotfix için DORA metrikleri: ortalama kurtarma süresi (MTTR) 1 saatten az olmalıdır.

# .github/workflows/hotfix-deploy.yml
name: Hotfix Deploy Pipeline
on:
  pull_request:
    types: [labeled]
    branches: [hotfix/*]

jobs:
  hotfix-checks:
    runs-on: ubuntu-latest
    if: contains(github.event.label.name, 'hotfix-critical')
    steps:
      - uses: actions/checkout@v4
      - name: Validate diff size
        run: bash .github/scripts/diff-check.sh 30
      - name: Build
        run: ./gradlew assembleRelease
      - name: Smoke test
        run: ./gradlew smokeTest
      - name: Deploy to staging
        run: fastlane deploy_staging
      - name: Approve & deploy to production
        if: success()
        run: fastlane deploy_production
        env:
          HOTFIX_MODE: true

Bu pipeline'daki temel optimizasyonlar: diff kontrolü (30 satırdan fazla değil), entegrasyon testlerini atlama, smoke testi başarılı olursa staging ve production'a otomatik dağıtım. HOTFIX_MODE ortam değişkeni, çalışma zamanında ek kontrolleri etkinleştirir — örneğin, hızlı sorun teşhisi için genişletilmiş günlük kaydı.

Git'te hotfix dalları: doğru strateji

Hotfix dallarıyla çalışma stratejisi Gitflow Workflow'da açıklanmıştır. Ana kural: hotfix dalı en son sürüm etiketinden (git checkout -b hotfix/v2.5.1 tags/v2.5.0) oluşturulur, develop veya main'den değil. Bu, hotfix'in şu anda üretimde olan aynı kod durumuna dayanmasını ve develop'tan bitmemiş değişiklikleri çekmemesini sağlar.

Düzeltme tamamlandıktan sonra, hotfix dalı main (veya master) ve develop'a birleştirilir. Main'e — yeni bir yama sürümü etiketiyle (v2.5.1) normal bir merge commit'i. Develop'a — ekip politikasına bağlı olarak merge veya cherry-pick. Develop, main'den daha fazla değişiklik içeriyorsa, çakışmaları önlemek için belirli hotfix commit'inin cherry-pick'ini yapmak önerilir. GitFlow, önce hotfix'in main'e, ardından main'in develop'a birleştirilmesini önerir.

# En son sürüm etiketinden hotfix dalı oluştur
git checkout -b hotfix/v2.5.1 tags/v2.5.0

# Düzeltmeyi uygula
git commit -m "HOTFIX: Fix crash on Android 14 notification permission"

# Main'e birleştir ve sürümü etiketle
git checkout main
git merge --no-ff hotfix/v2.5.1
git tag -a v2.5.1 -m "Hotfix release v2.5.1"

# Develop'a da birleştir
git checkout develop
git merge --no-ff hotfix/v2.5.1

# Geçici dalı temizle
git branch -d hotfix/v2.5.1

Önemli: hotfix mevcut develop dalında bulunan bir hatayı düzeltiyorsa (hata birkaç sprint önce eklenmişse), hotfix main ve develop'a birleştirildikten sonra develop zaten düzeltmeyi içerir. Hata yalnızca sürüm dalında eklenmişse (cherry-pick yoluyla birikmiş bir hata), develop'ta düzeltme gerekli olmayabilir. Kök neden analizi, develop'ta cherry-pick'in gerekli olup olmadığını belirlemeye yardımcı olur.

Hotfix riskleri ve nasıl en aza indirilir

Hotfix'in ana riski, acele nedeniyle yeni ve daha ciddi bir hata eklemektir. Stripe (2021) araştırmasına göre, hotfix'lerin %15'i gerilemeye neden olur ve ikinci bir hotfix gerektirir. Bu ironi yasasıdır: ne kadar hızlı düzeltirsek, hata yapma olasılığımız o kadar yüksek olur. Risk minimizasyonu, diff boyutunun sıkı bir şekilde sınırlandırılması (30 satırdan fazla değil) ve zorunlu otomatik smoke testleri ile sağlanır

İkinci risk — teknik borç birikimi. Bir ekip düzenli olarak planlı sürümler yerine hotfix kullanıyorsa, kod tabanı bozulur: hotfix commit'leri yeniden düzenlemeden geçmez, geçici çözümler uygun çözümlerle değiştirilmez, dokümantasyon güncellenmez. Sağlık kontrolü: hotfix'ler ayda bir defadan fazla yayınlanıyorsa — sürüm süreci gözden geçirilmelidir.

Üçüncü risk psikolojiktir. Düzenli hotfix'ler ekibi tüketir: nöbetçi geliştiriciler sürekli stres altındadır, kod incelemesi formaliteye dönüşür (herkes daha hızlı olmak ister) ve kalite kültürü düşer. Olgun bir ekip için normal hotfix sıklığı çeyrekte 1–2'dir. Daha fazlaysa — sorun hotfix'lerde değil, planlı sürümlerin kalitesindedir.

Hotfix'ten sonra ne yapılmalı

Hotfix dağıtıldıktan ve metrikler stabilize olduktan sonra, suçlayıcı olmayan bir post-mortem retrospektifi yapılır. Ekip dört soruyu yanıtlar: ne oldu, kontroller hatayı neden yakalamadı, düzeltmek için ne yapıldı ve tekrarı nasıl önlenir. Post-mortem, hotfix'ten sonraki 24–48 saat içinde, ayrıntılar hâlâ tazeyken yapılır. Suçlamama kültürü temel bir ilkedir: kişiler değil, süreçler tartışılır.

Post-mortem'in sonucu, sorumluları ve son teslim tarihleri olan somut eylem maddeleridir. Tipik eylem maddeleri: kaçırılan durum için birim testi eklemek, smoke test paketini genişletmek, izlemeyi iyileştirmek (metrik üzerinde uyarı eklemek), benzer olaylar için runbook'u güncellemek. Eylem maddeleri bir sonraki planlı sürümden önce tamamlanmalıdır.