Modern yazılım geliştirme süreçlerinde çevik (Agile) yaklaşımlar, ürün tesliminde esneklik ve kullanıcı odaklılık sağlar. Bu yaklaşım yalnızca kodlama sürecini değil, aynı zamanda sürüm planlama ve yayınlama stratejilerini de doğrudan etkiler. Agile’ın temel prensipleri, sürüm yayınlama planlarının daha şeffaf, sürdürülebilir ve kullanıcı geri bildirimiyle şekillenen bir yapıya kavuşmasını sağlar.
Bu yazıda, Agile çerçevesinde bir sürüm yayınlama planı nasıl hazırlanır, nelere dikkat edilmelidir, hangi araçlar kullanılır, sürüm takvimi nasıl optimize edilir gibi kritik soruları tüm ayrıntılarıyla yanıtlayacağız.
1. Agile Prensipleri ve Yayınlama Kültürü
Agile felsefesi, planlamadan çok adaptasyonu; belge üretiminden çok çalışan yazılımı; kapsamlı sözleşmelerden çok müşteri ile iş birliğini; plana bağlılıktan çok değişime yanıt vermeyi önceler. Bu değerler, sürüm planlarının da daha kısa aralıklarla, kullanıcı ihtiyaçlarına göre revize edilmesini gerektirir.
Agile ile sürüm planlamasında amaç:
-
Değer odaklı yazılım teslimi
-
Sürekli entegrasyon ve teslim (CI/CD)
-
Kullanıcıdan gelen geri bildirime göre iterasyon
-
Sürüm planlarını sprintlere uyumlu şekilde yapılandırmak
2. Sürüm Yayınlama Neden Planlanmalıdır?
Plansız yayınlama kaotik ve hatalara açık bir sürece yol açabilir. Özellikle birden fazla ekip, farklı ürün bileşenleri ve birçok ortam (test, staging, production) söz konusu olduğunda, planlama hayati hale gelir.
Yayınlama planı ne sağlar?
-
Net zaman çizelgesi
-
Sürümde yer alacak özelliklerin tanımı
-
Rollback (geri alma) senaryoları
-
Yayın sonrası görevlerin belirlenmesi
-
Hangi sprintte hangi modül yayınlanacak bilgisinin netliği
3. Sürüm Türleri: Major, Minor, Patch
Agile süreçlerinde, farklı sürüm tipleri için farklı planlama seviyeleri gerekir.
Sürüm Türü | Tanım | Örnek | Yayın Sıklığı |
---|---|---|---|
Major | Temel değişiklik | 2.0.0 | 3-6 ayda bir |
Minor | Yeni özellik | 2.1.0 | 2-4 haftada bir |
Patch | Hata düzeltmesi | 2.1.3 | Gerektikçe |
Bu sürüm yapısı, kullanıcıya değişiklik seviyesini önceden bildirmenin bir yoludur.
4. Agile’de Yayınlama Periyotları: Sprint ve Release İlişkisi
Bir Agile takımı genellikle sabit süreli sprintler ile çalışır (örneğin 2 haftalık sprint). Ancak her sprint sonunda yayınlama yapılması zorunlu değildir.
Olası yayınlama yaklaşımları:
-
Her Sprint Sonu Yayın: CI/CD sistemlerinin güçlü olduğu durumlarda
-
Birden Fazla Sprint Sonrası Yayın (Release Sprint): Daha büyük versiyonlar için idealdir
-
Feature Toggle ile Ertelenen Yayın: Özellik kodlanır ama belirli tarihte açılır
5. Yayınlama Planı Hazırlama Adımları
1. Sürüm Hedeflerinin Belirlenmesi
-
Hangi müşteri ihtiyacına hizmet ediyor?
-
Hangi modül(ler) geliştirilecek?
2. Teknik Gereksinimlerin Listelenmesi
-
API güncellemeleri
-
Veritabanı migrasyonları
-
Uygulama izinlerinde değişiklik
3. Sprint Planlama ile Entegrasyon
-
Yayına konu olacak iş paketleri hangi sprintlere dağılacak?
-
Test ve QA süresi ayrıldı mı?
4. Rollout Stratejisinin Belirlenmesi
-
Kademeli yayılım mı yapılacak (%10 → %50 → %100)?
-
Platformlara göre farklı yayınlama tarihi var mı?
5. Yayın Sonrası Geri Dönüş Mekanizması
-
Rollback nasıl yapılacak?
-
Firebase Crashlytics veya Sentry ile canlı hata takibi yapılacak mı?
6. Yayınlama Planında Kullanılan Araçlar
Jira
-
Epic → Story → Task hiyerarşisi ile sürüm altındaki işleri kategorize eder
Confluence
-
Yayınlama notları, zaman çizelgeleri ve iş akışları için dokümantasyon alanı
GitHub / GitLab
-
Release branches, pull request süreçleri
Google Play Console / App Store Connect
-
Sürüm yükleme ve kademeli dağıtım planlama
Slack / Microsoft Teams
-
Yayın zamanlarında ekip bilgilendirme ve bildirim
7. CI/CD Entegrasyonu ve Otomatik Yayınlama
Sürüm planı sadece teorik bir belge değil; aynı zamanda otomasyon süreçlerine entegre bir yapıda olmalıdır.
Jenkins, GitHub Actions, GitLab CI gibi araçlarla:
-
Her merge sonrası testler çalıştırılır
-
Beta yayına otomatik gönderim yapılabilir
-
Başarılı süreç sonrası production ortamına alınır
8. Yayınlama Öncesi Hazırlıklar
-
QA tarafından “Go/No-Go” raporu hazırlanır
-
Kullanıcı dokümantasyonu tamamlanır
-
Sürüm notları derlenir
-
App Store/Play Store metinleri güncellenir
-
Screenshot ve video tanıtımları eklenir
9. Yayınlama Anı ve Sonrası İzleme
Yayın sırasında:
-
Slack kanalında canlı takip yapılır
-
Performans izleme araçları devrededir
-
Sunucu trafik yükü izlenir
Yayın sonrası:
-
Crash raporları analiz edilir
-
Kullanıcı yorumları toplanır
-
A/B test sonuçları değerlendirilir
-
İlk 24 saatteki indirme istatistikleri yorumlanır
10. Geribildirim Döngüsü ve Sonraki Sürümün Planlanması
Agile’ın temel döngüsü olan “inspect and adapt” prensibi yayınlama sürecine de entegre edilmelidir.
Yayın sonrası yapılması gerekenler:
-
Retrospective toplantısı ile süreç değerlendirmesi
-
Geri bildirimlerin ürün backlog’una eklenmesi
-
Bir sonraki sürüm hedefinin belirlenmesi
11. Minimum Viable Release (MVR) Kavramı
MVP (Minimum Viable Product) kavramına benzer şekilde, Agile takımları bazen “Minimum Viable Release” hedefler. Bu, kullanıcının ihtiyacını karşılayacak en sade sürümdür.
Avantajı:
-
Hızlı yayın
-
Geri bildirim bazlı geliştirme
12. Agile Yayınlama Planı Örneği
Sprint No | Geliştirilen Özellik | Yayınlama Tipi | Yayın Tarihi |
---|---|---|---|
Sprint 1 | Giriş ekranı revizyon | Internal Beta | 12 Ağustos |
Sprint 2 | Ödeme modülü | Closed Beta | 26 Ağustos |
Sprint 3 | Tüm modüller | Production | 9 Eylül |
Bu plan sayesinde tüm ekip üyeleri ne zaman ne olacağını net biçimde bilir.
Sonuç: Planlı Yayın, Başarılı Ürün
Agile felsefesine uygun bir sürüm yayınlama planı sayesinde:
-
Yayın tarihleri netleşir
-
Hatalar azalır
-
Ekipler arası iletişim kuvvetlenir
-
Kullanıcı geri bildirimleri erken aşamada alınır
Plansız bir yayın, en iyi ürünün bile başarısız olmasına neden olabilir. Bu nedenle sürüm planı, Agile dünyasında bir lüks değil, gerekliliktir.