Release Checklist: Deploy Öncesi Kontrol Listesi Alios'ta

Release Checklist: Deploy Öncesi Kontrol Listesi Alios'ta

Cuma öğleden sonra. Release hazır, herkes eve gitmek istiyor. "Çabuk çıkalım" baskısıyla bir adım atlıyor. Prodüksiyonda kritik bir şey kırılıyor. Hafta sonu kriz modu.

Bu senaryo "dikkatli olunsa önlenirdi" kategorisine giriyor. Ama dikkat tek başına yetmiyor. İnsan beyni baskı altında ve yorgunken adım atlıyor — bu bilişsel bir gerçek. Çözüm daha dikkatli olmak değil, atlanabilecek adımları sisteme koymak.

Release checklist bunun için var. Pilotların uçuş öncesi kontrol listesi kullanması "uçmayı bilmiyorlar" anlamına gelmiyor. Kritik adımların hafızaya değil, sisteme bağlı olması gerektiği anlamına geliyor.

Release Sırasında Neler Unutuluyor?

Release sürecinde atlanan adımlar genellikle üç kategoride toplanıyor.

Teknik kontroller: Staging'de test edilmeden canlıya çıkılıyor. Environment variable'lar production ortamı için güncellenmemiş. Database migration çalıştırılmamış. Rollback planı yapılmamış.

İletişim adımları: Müşterilere önceden bildirim gönderilmedi. Ekip canlıya çıkıştan haberdar edilmedi. Changelog güncellenmedi. Destek ekibine yeni özellik hakkında bilgi verilmedi.

Doğrulama adımları: Canlıya çıkış sonrası smoke test yapılmadı. Monitoring alarmları kontrol edilmedi. İlk 24 saat izleme planlanmadı.

Bu adımların her biri tek başına küçük görünüyor. Ama birkaçı aynı anda atlandığında prodüksiyon olayı kaçınılmaz hale geliyor.

Alios'ta Kopyalanabilir Release Checklist

Alios'ta release checklist bir kez kuruluyor, her release öncesi kopyalanıyor. Kopyalama şöyle çalışıyor: şablon node kopyalanıyor, başlık "[Versiyon] — Release — [Tarih]" olarak güncelleniyor, sorumlu atanıyor. Geri kalan her madde hazır bekliyor.

Bu yaklaşımın iki faydası var: hiçbir adım atlanmıyor çünkü liste standart, ve her release'in geçmişi arşivde duruyor çünkü node silinmiyor.

Aşağıdaki şablon doğrudan Alios'ta kullanılabilir.

📁 RELEASE [Versiyon] — [Tarih]

Sorumlu: [Release sahibi]
Planlanan canlıya çıkış: [Tarih / Saat]
Ortam: Production
Release notu linki: [Varsa]

ÖN HAZIRLIK — Release'den 48 Saat Önce

- [ ] Tüm feature branch'leri main'e merge edildi
- [ ] Conflict çözümlendi, CI/CD pipeline yeşil
- [ ] Staging ortamına deploy edildi
- [ ] Database migration script'leri hazır ve test edildi
- [ ] Environment variable değişiklikleri listelendi
- [ ] Rollback planı yazıldı — hangi adımlarla geri dönülür
- [ ] Release notu taslağı hazırlandı
- [ ] Bağımlı servisler veya third-party entegrasyonlar
      kontrol edildi — breaking change var mı?

STAGİNG TESTİ — Release'den 24 Saat Önce

- [ ] Smoke test tamamlandı — temel akışlar çalışıyor
- [ ] Kritik kullanıcı senaryoları test edildi
      [ ] Kayıt / Giriş akışı
      [ ] Ödeme akışı (varsa)
      [ ] Temel CRUD işlemleri
      [ ] Bildirim akışı (varsa)
- [ ] Mobil görünüm kontrol edildi (varsa)
- [ ] Performans regresyonu yok — yükleme süreleri karşılaştırıldı
- [ ] Yeni özellikler için kabul kriterleri staging'de karşılandı
- [ ] Bu release'te düzeltilen bug'lar staging'de doğrulandı
- [ ] QA onayı alındı: [İsim] — [Tarih]

İLETİŞİM — Release'den 24 Saat Önce

- [ ] Ekip canlıya çıkış tarihi ve saatinden haberdar edildi
- [ ] Destek ekibine yeni özellikler hakkında brifing verildi
- [ ] Planlı kesinti varsa müşterilere önceden bildirildi
- [ ] Müşteri bildirimi hazırlandı (yeni özellik duyurusu)
      Gönderim tarihi: [Tarih]
- [ ] Sosyal medya veya blog içeriği hazır (varsa)

DEPLOY ÖNCESİ — Canlıya Çıkıştan 1 Saat Önce

- [ ] Son kez staging kontrol edildi — herhangi bir değişiklik var mı
- [ ] Database backup alındı
- [ ] Environment variable'lar production için güncellendi
      [ ] API key'ler
      [ ] Database bağlantı stringleri
      [ ] Feature flag'ler
      [ ] Third-party servis konfigürasyonları
- [ ] Monitoring ve alarm sistemi aktif — baseline kontrol edildi
- [ ] Rollback prosedürü ekiple paylaşıldı
- [ ] On-call kişi belirlendi — release sonrası ilk 2 saat
- [ ] "Deploy başlıyor" ekibe bildirildi

DEPLOY — Canlıya Çıkış

- [ ] Deploy komutu çalıştırıldı
- [ ] Pipeline başarıyla tamamlandı
- [ ] Database migration çalıştırıldı ve doğrulandı
- [ ] Uygulama ayağa kalktı, health check yeşil
- [ ] "Deploy tamamlandı" ekibe bildirildi — saat: [Saat]

DEPLOY SONRASI — İlk 30 Dakika

- [ ] Production smoke test yapıldı
      [ ] Temel akışlar çalışıyor
      [ ] Yeni özellikler çalışıyor
      [ ] Kritik bug'lardan etkilenen alanlar kontrol edildi
- [ ] Error rate kontrol edildi — anormal artış yok
- [ ] Response time kontrol edildi — regresyon yok
- [ ] Log'lara bakıldı — beklenmeyen hata yok
- [ ] Monitoring alarm baseline normale döndü
- [ ] "Release başarılı" ekibe bildirildi

RELEASE KAPANIŞI — İlk 24 Saat

- [ ] Changelog güncellendi ve yayınlandı
- [ ] Müşteri bildirimi gönderildi (planlanmışsa)
- [ ] Release notu yayınlandı
- [ ] Destek ekibine "canlıda" bilgisi verildi
- [ ] 24 saat izleme tamamlandı — anormal durum yok
- [ ] Release node'u "Done" olarak kapatıldı
- [ ] Release retrospektif notu eklendi:
      Ne iyi gitti: [1-2 cümle]
      Ne zorladı: [1-2 cümle]
      Bir dahaki release'te ne değişecek: [1 madde]

Checklist'i Ekibe Göre Özelleştirme

Yukarıdaki şablon genel bir başlangıç noktası. Her ekibin kendi stack'ine ve sürecine göre özelleştirmesi gerekiyor.

Çıkarılabilecek maddeler: Mobil uygulama yoksa mobil kontroller çıkıyor. Planlı kesinti olmayan release'ler için müşteri bildirimi zorunlu değil. Küçük hotfix'ler için 48 saatlik hazırlık penceresi gerekmiyor.

Eklenebilecek maddeler: Kubernetes ortamında çalışıyorsa pod health kontrolleri ekleniyor. Multi-region deployment varsa her bölge için ayrı kontrol satırı. A/B test açılıyorsa feature flag konfigürasyonu.

Stack'e özgü maddeler:

AWS için:
- [ ] CloudFormation stack güncellendi
- [ ] S3 bucket policy'leri kontrol edildi
- [ ] CloudFront cache invalidation yapıldı

Kubernetes için:
- [ ] Deployment manifest güncellendi
- [ ] Resource limit'ler kontrol edildi
- [ ] Pod'lar Healthy durumda

Veritabanı migration için:
- [ ] Migration idempotent — iki kez çalıştırılsa sorun olmaz
- [ ] Rollback migration hazır
- [ ] Migration süresi tahmin edildi — kesinti penceresi yeterli mi

Acil Release Protokolü

Hotfix veya kritik bug fix için tam checklist çok uzun olabilir. Bu durumlar için kısaltılmış versiyon:

📌 ACİL RELEASE — [Açıklama]

ZORUNLU KONTROLLER:
- [ ] Fix staging'de test edildi — bug üretilemiyor
- [ ] Başka şeyleri kırmıyor — hızlı regresyon testi
- [ ] Database backup alındı (migration varsa)
- [ ] Rollback adımları belli
- [ ] Ekip haberdar edildi

DEPLOY SONRASI:
- [ ] Production'da doğrulandı
- [ ] Error rate normal
- [ ] Tam checklist geriye dönük tamamlanacak: [Tarih]

Acil release protokolü "full checklist'i atlıyoruz" değil, "şimdi kritik olanları yapıyoruz, geri kalanı belgeleyeceğiz" anlamına geliyor.

Son Düşünce

Release checklist deploy kontrolü pilotların pre-flight checklist'i gibi çalışıyor: uçmayı bilen kişiler kullanıyor çünkü kritik adımların hafızaya değil, sisteme bağlı olması gerekiyor.

Alios'ta bu checklist'i kopyalanabilir node olarak tutmak iki şeyi garanti ediyor: her release aynı standartla çıkıyor, her release'in geçmişi arşivde kalıyor.

Cuma öğleden sonrası baskısında unutulan adım prodüksiyon olayına dönüşmüyor. Çünkü adım unutulmuyor — liste var.