Uygulama Yayına Çıktıktan Sonra: Bakım ve Sürüm Yönetimi
Mobil uygulama yayına çıkınca iş bitmez; işletim sistemi güncellemeleri, mağaza sürüm zorunlulukları ve bakım takvimi nasıl yönetilir anlatıyoruz.
rabbitclip ekibiYayın: 5 dk okuma
Kısa cevap
Bir mobil uygulama yayına çıktıktan sonra yılda birkaç kez güncellenmesi gerekir; işletim sistemi sürümleri, mağaza kuralları ve kütüphaneler değiştiği için bakım yapılmayan uygulama bir süre sonra çalışmaz ya da mağazadan kaldırılır.
Web sitesinden farkı burada. Bir web sayfası tarayıcı güncellendiğinde genelde sorunsuz açılmaya devam eder; mobil uygulama işletim sistemi güncellendiğinde uyumsuz kalabilir, mağaza yeni bir minimum kural getirdiğinde güncellenmeyen sürüm listeden düşebilir.
Bu yazıda bakımın gerçekte ne olduğunu, hangi zorunlulukların takvimi belirlediğini ve bu işi kimin üstlenmesi gerektiğini, gerçek bir örnekle birlikte anlatıyoruz.
Bakım gerçekte ne demek
Bakım, uygulamanın kullandığı kütüphanelerin, işletim sistemi uyumluluğunun ve mağaza politikalarının güncel tutulmasıdır; yeni özellik eklemekten ayrı bir iştir ve düzenli, öngörülebilir bir takvimde yürütülür.
Bir uygulama bir kere yazılıp bırakılabilecek bir ürün değildir; canlı kalan her yazılım gibi çevresi değiştikçe kendisinin de değişmesi gerekir.
Bu ayrımı netleştirmek önemli: bakım, uygulamayı olduğu gibi ayakta tutmaktır; yeni özellik geliştirme ise uygulamayı büyütmektir. İkisi aynı ekip tarafından yapılabilir ama farklı bütçe kalemleri olarak ele alınmalı, aksi halde bakım ihtiyacı büyüme çalışmasının gölgesinde kalır.
İşletim sistemi güncellemeleri neden zorlar
Apple ve Google yılda bir büyük işletim sistemi sürümü çıkarır; yeni sürümle birlikte bazı API'ler kullanımdan kaldırılır, bazı izin davranışları değişir. Bir önceki yıl sorunsuz çalışan kod, yeni sürümde beklenmedik biçimde davranabilir.
Bu yüzden her büyük işletim sistemi sürümü çıktığında uygulamanın o sürümde test edilmesi gerekir; bu test yapılmadan güncelleme geciktirilirse kullanıcı şikayetleri artar.
Örneğin bir izin isteme akışı, bir önceki sürümde tek ekranda toplanmışken yeni sürümde iki adıma bölünebilir; kod çalışmaya devam eder ama kullanıcı beklediği ekranı göremez. Bu tür değişiklikler ancak gerçek testte fark edilir, kod incelemesinde görünmez.
Mağaza tarafındaki zorunlu güncellemeler
Google Play her yıl minimum hedef API seviyesini yükseltir; bu seviyenin altında kalan uygulamalar yeni kurulum ve güncelleme alamaz hale gelir. Bu, kod bozulmasa bile uygulamanın mağazadan pratikte kaybolması demektir.
Apple tarafında benzer biçimde, eski SDK ile derlenmiş uygulamalar bir süre sonra gönderim için kabul edilmez; yıllık bir yeniden derleme ve test döngüsü bu yüzden gereklidir.
Bu zorunluluklar genelde önceden duyurulur; takvimi takip eden bir ekip için sürpriz değildir, takip etmeyen bir ekip için ise uygulamanın aniden 'kaybolduğu' bir gün olarak yaşanır.
Bir bakım takvimi nasıl kurulur
Pratikte işe yarayan yapı, yılda iki ya da üç sabit bakım penceresi tanımlamaktır: kütüphane güncellemesi, yeni işletim sistemi testi, mağaza politika kontrolü. Bu pencereler dışında sadece kritik hata çıkarsa acil müdahale yapılır.
Bu pencerelerin tarihi, işletim sistemlerinin yıllık çıkış döngüsüne göre önceden belirlenebilir; böylece bakım, sürpriz bir hatırlatmayla değil, takvimde zaten yer alan bir görevle yürütülür.
- Yeni işletim sistemi sürümü çıktığında uyumluluk testi
- Mağaza hedef API/SDK zorunluluğu güncellendiğinde derleme yenileme
- Kullanılan üçüncü parti kütüphanelerin güvenlik güncellemeleri
- Kullanıcı yorumlarının ve çökme raporlarının düzenli takibi
Bakım yapılmazsa ne olur
En hafif senaryoda uygulama giderek yavaşlar ya da bazı ekranlarda hata verir. En ağır senaryoda mağaza, hedef API seviyesi eskidiği için uygulamayı yeni kullanıcılara kapatır ya da tamamen kaldırır. İkisi de geri dönüşü zaman alan durumlardır.
Bir mobilya atölyesinin iki yıl güncellenmemiş bayi uygulaması, Google Play'in hedef API seviyesini yükseltmesiyle yeni kurulum alamaz hale geldi; bayiler telefon değiştirdiğinde uygulamayı yeniden kuramadı. Sorunun kendisi bir haftada çözüldü ama fark edilmesi altı aya yakın sürdü, çünkü kimse düzenli olarak bakmıyordu.
Bakımı kim üstlenmeli: içeride mi, ajansta mı
Küçük bir işletmede tek bir kişiye 'bizim uygulamaya da bakar mısın' demek cazip görünür ama bakım, o kişinin asıl işinin arasına sıkışan, önceliği sürekli ertelenen bir iş haline gelir. Bu, bakımın fiilen yapılmadığı en sık senaryodur.
Karar kriteri şu olmalı: uygulamanın yıllık bakım yükü (test, derleme, mağaza kontrolü) tek bir kişinin düzenli, tekrarlanabilir bir görevi olabilecek kadar mı küçük, yoksa ayrı bir bütçe ve takvim mi gerektiriyor. İkincisi doğruysa, bakımı dışarıdan bir ekibe düzenli bir anlaşmayla vermek, işin arada kaybolmasını önler.
Dışarıdan bir ekiple çalışmanın asıl faydası, o ekibin işletim sistemi ve mağaza değişikliklerini zaten takip eden, bunu birden fazla uygulama için tekrar eden bir düzeni olmasıdır; işletme kendi başına her yıl aynı bilgiyi yeniden öğrenmek zorunda kalmaz.
Sık yapılan hatalar
En sık hata, bakımı 'bir sorun çıkarsa bakarız' mantığıyla ele almaktır; oysa mağaza zorunlulukları sorun çıkmadan, sessizce devreye girer ve uygulama fark edilmeden listeden düşebilir. Bakım, reaktif değil, takvimli bir iş olmalı.
İkinci hata, yeni işletim sistemi sürümünü resmi çıkışında test etmektir; oysa beta sürümü yayınlandığı andan itibaren test etmek, resmi sürüm çıkana kadar sorunları görüp düzeltme fırsatı verir. Üçüncü hata, bakım bütçesini ilk yıl planlayıp ikinci yıldan itibaren unutmaktır; bakım tek seferlik bir kalem değil, uygulama canlı kaldığı sürece süren bir maliyettir.
- Bakımı yalnızca sorun çıktığında hatırlamak
- Yeni işletim sistemini yalnızca resmi sürümde test etmek
- Bakım sorumluluğunu tek kişiye, yazılı bir takvim olmadan bırakmak
Yayına çıkış bir bitiş değil, düzenli bir bakım döngüsünün başlangıcıdır; bu döngü önceden tanımlı bir takvimle yürütüldüğünde sürpriz olmaz, tanımsız bırakıldığında ise fark edilmesi aylar süren sessiz bir soruna dönüşür. Uygulamanız için bir bakım takvimi henüz yoksa bunu birlikte kurabiliriz.
Sık sorulanlar
Bir uygulama hiç güncellenmezse ne olur?
Bir süre sorunsuz çalışabilir ama işletim sistemi ya da mağaza kuralı değiştiğinde uyumsuz kalır, en sonunda mağazadan yeni kurulum için kapanabilir.
Bakım için yılda kaç güncelleme yeterli?
Genelde iki ya da üç planlı güncelleme yeterlidir; ciddi bir hata çıkarsa bunun dışında acil güncelleme yapılır.
Yeni işletim sistemi çıktığında hemen mi test edilmeli?
Genellikle beta sürümü yayınlandığında test edilmesi, resmi sürüm çıkana kadar sorunların önceden görülmesini sağlar.
Bakım anlaşması olmadan uygulama riske girer mi?
Zamanla evet; kimse takip etmezse mağaza zorunlulukları ya da işletim sistemi değişiklikleri fark edilmeden geçebilir.
Bakımı tek kişiye bırakmak neden risklidir?
O kişinin asıl işi öncelik kazandığında bakım sessizce ertelenir; yazılı bir takvim ve yedek sorumlu olmadan bu iş kolayca gözden kaçar.
