Uygulama geliştirmede yayın günü: özü, aşamaları ve hazırlık
Yayın günü (release day), build hazırlığı, mağaza incelemesi, aşamalı kullanıma sunma (staged rollout) ve izlemeyi içeren, mobil uygulamanın yeni bir sürümünün yayınlanması için planlanan tarihtir. iOS uygulamaları için süreç, Apple’ın zorunlu incelemesi nedeniyle planlanan yayın tarihinden 24-48 saat önce build’in App Store Connect’e yüklenmesiyle başlar. Android için build, Google Play Console’da derlenir ve yüklenir; burada inceleme süreci genellikle 1-4 saat sürer. Apple Developer Guidelines (2025)’a göre, build’lerin %90’ı 24 saat içinde incelemeyi geçer. Aşamalı kullanıma sunma, yayınlamadan sonra hatalar keşfedilirse etkiyi en aza indirmeye yardımcı olur.
Kilit noktalar
- Yayın günü — build hazırlığından kullanıma sunma sonrası izlemeye kadar faaliyetler bütünü
- Aşamalı kullanıma sunma — kademeli dağıtım: %1, %10, %50, %100
- Smoke testi — build’i mağazaya göndermeden önce son kontrol
- Rollback planı — kritik hatalar için önceden hazırlanmış rollback senaryosu
- Yayın retrospektifi — %100 kullanıma sunma tamamlandıktan sonra süreç analizi
Yayın günü nedir ve nasıl hazırlanılır
Yayın günü sadece Yayınla düğmesine basma anı değildir. Geliştiriciler, QA, DevOps, ürün yöneticileri ve bazen destek ekibinin katıldığı koordineli bir süreçtir. Hazırlık yayın gününden 2-3 hafta önce başlar: kapsamın belirlenmesi, kod dondurma, regresyon testi, yayın notları ve pazarlama materyallerinin hazırlanması. Hazırlık ne kadar titiz olursa, yayın günü o kadar sorunsuz geçer.
Yayın günü hazırlık kontrol listesi şunları içerir: yayın build’i üzerinde son QA çalıştırması (regresyon + smoke paketi); mağazalardaki meta verilerin kontrolü (ad, açıklama, ekran görüntüleri, anahtar kelimeler); ürün yöneticisi ile aşamalı kullanıma sunma yüzdesi üzerinde anlaşma; rollback planının hazırlanması (hangi etiketin yeniden dağıtılacağı, ne kadar süreceği); yaklaşan yayın hakkında ekibin ve ilgili hizmetlerin bilgilendirilmesi. Yayın kontrol listesi CI/CD aracılığıyla otomatikleştirilmelidir — örneğin, yayın etiketini oluşturmadan önce tüm maddeleri kontrol eden bir GitHub Actions iş akışı olarak.
Hazırlığın önemli bir unsuru, karartma dönemidir (blackout period) — üretime dağıtımın yasak olduğu dönem. Genellikle karartma, yayın gününden 48 saat önce başlatılır ve başarılı %100 kullanıma sunmadan 24 saat sonra kaldırılır. Değişiklik dondurma karartma döneminde yayınla ilgili tüm hizmetler için geçerlidir.
Build hazırlığı: kod dondurma, etiketleme ve derleme
Yayın gününden 24-48 saat önce, kod dondurma (code freeze) uygulanır — kod değişikliklerinin tamamen durdurulması. Geliştiriciler dokümantasyon ve yayın notları hazırlamaya odaklanır. DevOps, sabit bir etiketten (ör. v2.6.0-rc1) yayın build’ini derler. Build, tam regresyon paketinden (otomatik + manuel testler) geçer. Kritik hatalar bulunursa, kod dondurmadan önce düzeltilir veya yayın ertelenir. Yayın adayı (RC) — QA’yı geçmiş ve mağazaya gönderilmeye hazır build.
Git’te etiketleme: açıklamalı bir etiket oluşturulur (git tag -a v2.6.0 -m “Release v2.6.0”). CI/CD boru hattı, Google Play için AAB (Android App Bundle) ve Apple App Store için IPA (iOS App Store Package) oluşturur. Build’e şunlar eşlik eder: sağlama toplamı dosyası (SHA256), değişiklik günlüğü ve bilinen sorunlar listesi (known issues). Tekrarlanabilir build’ler — aynı etiketten yeniden derlemenin ikili olarak aynı sonucu ürettiği ideal bir uygulama.
bash
# Yayın boru hattı — etiket oluşturma ve derleme
# Kod dondurmanın zaten aktif olduğunu varsayar
# develop’tan yayın dalı oluştur
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Kod dondurma: dal koruma kuralları yeni PR’ları engeller
# CI/CD’de regresyon paketini çalıştır
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Başarılı QA’dan sonra yayın etiketi oluştur
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# CI/CD aracılığıyla yayın ikili dosyasını derle
# fastlane build_release AAB + universal APK üretir
fastlane build_releaseÖnemli: sürüm yükseltme (version code ve version name güncelleme) kod dondurmadan önce yapılır. Kod dondurmadan sonra sürüm değişmez. Android için: versionCode — tekdüze artan tam sayı; versionName — anlamsal sürüm (2.6.0). iOS için: CFBundleVersion (build numarası) ve CFBundleShortVersionString (anlamsal sürüm). Sürümleme gradle/xcconfig’de otomatikleştirilmelidir.
Mağazaya yükleme ve inceleme süreci
iOS için: build, Xcode, Transporter veya fastlane aracılığıyla App Store Connect’e yüklenir. Yüklemeden sonra build, Apple’ın otomatik kontrolünden (processing) geçer ve ardından manuel incelemeye gönderilir. Ortalama inceleme süresi 24 saattir, ancak Apple incelemecilerinin iş yükü ve uyumluluk gereksinimlerine bağlı olarak 1 saat ile 7 gün arasında değişebilir. Hızlı inceleme — kritik hata düzeltmeleri için hızlandırılmış inceleme talebi (ayda bir defadan fazla kullanılamaz, garantili değildir).
Android için: build, Google Play Console aracılığıyla yüklenir. Google, otomatik test (erişilebilirlik, kötü amaçlı yazılım, politika uyumu) + seçici manuel incelemenin birleşik bir yaklaşımını kullanır. Ortalama inceleme süresi 1-4 saattir. Dahili test kanalı ve Kapalı kanal, Üretim kanalında yayınlamadan önce son testlere olanak tanır. Öneri: Dahili testte 1-2 gün → Kapalı betada 1 gün → kademeli Üretim kullanıma sunumu.
Her iki platform için de build’i yüklemeden önce meta verileri kontrol etmek çok önemlidir: uygulama adı, açıklama (kısa + tam), desteklenen her cihaz için ekran görüntüleri (iPhone 6,5″, 5,5″, iPad, Android telefon, tablet), anahtar kelimeler (iOS) veya mağaza listeleme deneyleri (Android). Meta verilerdeki bir hata, incelemeyi ek bir gün geciktirebilir. Uygulama meta verileri desteklenen tüm dillerde yerelleştirilmelidir.
Aşamalı kullanıma sunma: risksiz yayın dağıtımı
Aşamalı kullanıma sunma (kademeli dağıtım, aşamalı dağıtım), yeni bir sürümün kullanıcılara hemen değil, aşamalı olarak sunulduğu bir stratejidir. Olgun bir ekip için tipik bir şema: kullanıcıların %1’i (ilk 2-4 saat) → %10 (24 saat) → %25 (24 saat) → %50 (24 saat) → %100. Her aşama metrik izleme ve kritik hata olmadığının kontrolünü içerir. Aşamalı kullanıma sunma, yayınlar sırasında riski en aza indirmek için birincil araçtır.
Google Play Console, yerleşik aşamalı kullanıma sunma sunar: bir kullanıcı yüzdesi belirleyebilir ve kademeli artışlar planlayabilirsiniz. iOS App Store Connect için böyle bir yerleşik özellik yoktur — aşamalı kullanıma sunma, Aşamalı Yayın (7 gün boyunca otomatik kapsam artışı, duraklatma imkanı ile) veya coğrafi dağıtımla sunucu tarafı özellik bayrakları aracılığıyla uygulanır. Aşamalı Yayın, App Store Connect’te sorun tespit edilirse Yayını Duraklatma imkanı sağlar.
Bir sonraki aşamaya geçmek için temel metrikler: hatasız kalma oranı (yeni yayın için ≥%99,9), ANR oranı (Android, ≤%0,1), backend API’sinde hata oranı (≤%0,5 5xx), kullanıcı puanları (önceki sürümden düşük değil), apdex puanı (≥0,94). Herhangi bir metrik eşiği aşarsa, neden belirlenene kadar kullanıma sunma duraklatılır. Go/no-go kapısı her aşamada yayın yöneticisinin veya nöbetçi mühendisin sorumluluğundadır.
Yayın sonrası izleme: ilk saatlerde nelere bakılmalı
Yayından sonraki ilk 4 saat en kritik zamandır. Ekip, çökme oranını (Sentry, Firebase Crashlytics, App Center), backend’deki 5xx hata oranını, özel olayları (başarılı ödemeler, girişler, kayıtlar), App Store ve Google Play’deki kullanıcı puanlarını ve sosyal medya bahislerini (Twitter, Reddit) izler. İzleme panosu önceden hazırlanmalı ve ofiste büyük bir ekranda veya özel bir Slack kanalında erişilebilir olmalıdır. Yayın panosu — tüm yayın metrikleri için tek bir pencere.
Regresyon metriklerine özel dikkat: benzer bir dönemde önceki sürümle çökme oranını karşılaştırma. Çökme oranı %0,1’den fazla arttıysa, bu acil analiz gerektiren bir kırmızı bayraktır. Ana API uç noktalarının medyan ve p95 gecikmesini karşılaştırmak da önemlidir: çökme olmasa bile, yanıt süresinde 200ms’lik bir artış bir soruna işaret edebilir. Metrik karşılaştırması (temel çizgi vs güncel) Datadog veya Grafana’da otomatikleştirilir.
Kullanıcı geri bildirimi sayısal metrikler kadar önemlidir. Bir yayından sonraki ilk saatlerde, kullanıcılar mağazalarda aktif olarak yorum bırakır ve desteğe yazar. Testler tarafından yakalanmayan hatalar, yorumlarda hızla ortaya çıkar. Ekip lideri veya belirlenmiş bir QA mühendisi, ilk 4 saat boyunca her 30 dakikada bir yorumları izler ve sınıflandırır: yanlış pozitif, bilinen sorun (zaten known issues listesinde), yeni hata. Yeni hatalar P0/P1 — kullanıma sunmayı duraklatma tetikleyicisi.
Rollback: yayın ne zaman ve nasıl geri alınır
Rollback, kritik sorunlar keşfedildiğinde önceki kararlı sürüme geri dönmektir. Rollback kararı, yayın yöneticisi tarafından teknik liderle birlikte şu durumlarda verilir: yeni yayının hatasız kalma oranı %99’un altına düştüğünde, veri sızıntısı tespit edildiğinde, kritik işlevsellik (ödemeler, kimlik doğrulama) kullanıcıların %5’inden fazlası için çalışmadığında veya mağaza (App Store Review) yayınlamadan sonra build’i reddettiğinde. Rollback tetikleyicisi, kararın duygulara değil gerçeklere dayanması için yayından önce tanımlanmalıdır.
Android için: Google Play Console’da rollback, aşamalı kullanıma sunmayı durdurmak ve önceki sürüme geçmek anlamına gelir. Mevcut build zaten kullanıcıların %100’ündeyse, önceki sürümü yeni bir yayın olarak yayınlayın. iOS için: App Store Connect aracılığıyla — Aşamalı Yayın → Yayını Duraklat → düzeltmeyle yeni bir sürüm yayınlama (App Store önceki bir sürüme geri dönmeye izin vermez). iOS rollback’i daha karmaşıktır: geliştiricinin geri alma commit’leriyle yeni bir build derlemesi ve incelemeyi yeniden geçmesi gerekir.
Rollback’ten sonra ekip olay moduna geçer: kök neden analizi, acil düzeltme veya düzeltmeyle sonraki yayın, olay sonrası değerlendirme. Rollback bir başarısızlık değil, standart bir prosedürdür. Hiç rollback yapmamış ekipler muhtemelen sorunları fark etmiyordur, hatasız yayınlar yaptıkları için değil. Rollback oranı DORA metriklerinden biridir: yüksek performanslı ekipler yayınların %10’undan daha azında rollback yapar ve 1 saatten kısa sürede kurtarır.
Sıkça sorulan sorular
Mobil uygulama yayınlamak için en iyi gün hangisidir?
En iyi günler Salı, Çarşamba veya Perşembedir. Pazartesi hafta sonundan yüksek trafik alır ve Cuma, sorunlu bir yayınla hafta sonuna girme riski taşır. Cumadan kaçının: dağıtımdan sonra bir sorun keşfedilirse, ekip hafta sonu boyunca düzeltme yapacak veya Pazartesiye kadar bekleyecektir.
App Store Review build’i reddederse ne yapmalı?
Resolution Center’da reddetme nedenini okuyun, düzeltin ve build’i yeniden yükleyin. Yaygın nedenler: kırık bağlantılar, eksik alanlar, abonelik olmadan içerik (gerekiyorsa), güncel olmayan ekran görüntüleri. App Review reddi yayını 24-48 saat geciktirir, bu nedenle ilk build yüklemesi planlanan yayın tarihinden 3-5 gün önce yapılmalıdır.
Başlamak için aşamalı kullanıma sunma yüzdesi ne kadar olmalı?
Büyük yayınlar (önemli değişiklikler) için — %1. Yama yayınları için — %5-10. İlk aşama, hata durumunda etkinin en aza indirilmesi için yeterince küçük, ancak istatistiksel olarak anlamlı metrikler elde etmek için yeterince büyük olmalıdır. 10 milyon kullanıcılı bir uygulama için %1, 100.000 kişi demektir — kritik sorunları tespit etmek için yeterlidir.
Yayın partisi yapılmalı mı?
Yayın partisi (ekip kutlaması) isteğe bağlıdır ancak moral için faydalıdır. Build yükleme anında değil, başarılı %100 kullanıma sunmadan sonra yapmak daha iyidir. Yayın kutlaması, neyin iyi gittiğini ve neyin iyileştirilebileceğini tartışmak için bir yayın retrospektifiyle birleştirilebilir.
“Yayınla veya ertele” kararından kim sorumludur?
Sorumluluk yayın yöneticisine (genellikle kıdemli bir mühendis veya teknik lider) aittir. Karar, son teslim tarihine değil, yayın panosundaki verilere dayanarak verilir. Yayın yöneticisi, metrikler go/no-go kapısını geçemezse yayını geciktirme yetkisine sahiptir.
Özet
- Yayın günü — kod dondurmadan kullanıma sunma sonrası izlemeye kadar koordineli süreç
- Hazırlık — yayın adayı, QA çalıştırması, meta veri kontrolü, rollback planı
- Aşamalı kullanıma sunma — %1 → %10 → %25 → %50 → %100, her aşamada go/no-go kapısı
- İzleme — hatasız kalma oranı, ANR, 5xx hata oranı, ilk 4 saatte kullanıcı puanları
- Rollback — hatasız kalma oranı %99’un altına düştüğünde standart prosedür
- İletişim — yayından önce ve sonra ekibi ve paydaşları bilgilendirme
- Yayın retrospektifi — %100 kullanıma sunma tamamlandıktan sonra süreç incelemesi
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun