Mobilde Sürüm Yönetimi: Kademeli Yayın, Geri Alma ve Zorunlu Güncelleme

Web tarafında hatalı bir dağıtım yaptığınızda yapacağınız şey bellidir: bir önceki sürüme dönersiniz, birkaç dakika içinde herkes düzelmiş halini görür. Mobilde böyle bir düğme yok. Kullanıcının telefonundaki sürüm, o kullanıcı güncellemeye karar verene kadar orada duruyor. Mağazadan kaldırsanız bile, indirmiş olanlarda hiçbir şey değişmiyor.

Bunu ilk defa canlı bir sorunda anladım: sunucu tarafında yaptığım bir değişiklik, eski sürümdeki bir ayrıştırma koduyla uyuşmadı ve o sürümü kullanan herkes için bir ekran çalışmaz hale geldi. Uygulamayı düzeltip yeni sürüm göndermek dört gün sürdü — inceleme dahil. O dört gün boyunca yapabildiğim tek şey sunucu tarafını eski davranışa döndürmekti.

O günden sonra kurduğum düzen, tek bir varsayıma dayanıyor: yayınladığım her sürüm, en az bir yıl daha sahada çalışacak.

Kademeli yayın: hatayı herkese değil, birkaç kişiye göstermek

Google Play’de bir sürümü kullanıcıların yüzde biriyle başlatıp adım adım artırabiliyorsunuz. App Store tarafında da yedi güne yayılan aşamalı bir yayın seçeneği var. İkisini de artık istisnasız kullanıyorum.

İzlediğim ritim şöyle:

Kritik nokta şu: kademeli yayının bir anlamı olması için o aşamalarda gerçekten bakmanız gerekiyor. Yüzde birde bırakıp ertesi gün yüzde yüze çekmek, kademeli yayın yapmak değil, sadece yayını geciktirmek.

Sunucu tarafı anahtarlar: uygulamanın içinde tutmadığım kararlar

Mobilde geri alma düğmesi olmadığı için, geri alınabilir olması gereken her kararı uygulamanın dışına taşıyorum. Pratikte bu, uygulama açılışında sunucudan çektiğim küçük bir yapılandırma nesnesi demek:

{
  "asgariSurum": "3.2.0",
  "onerilenSurum": "3.6.1",
  "bakimModu": false,
  "bakimMesaji": "",
  "ozellikler": {
    "yeniOdemeAkisi": true,
    "haritaKumelemesi": true,
    "sohbet": false
  },
  "apiTabani": "https://api.ornek.com/v3"
}

Bu nesnenin sağladığı şeyler:

• Yeni bir özelliği kapatabiliyorum. Ödeme akışında sorun çıkarsa, yeni sürüm beklemeden eski akışa dönüyorum.
• Bakım penceresi ilan edebiliyorum. Arka uçta planlı bir kesinti varsa kullanıcı hata ekranı yerine açıklayıcı bir mesaj görüyor.
• Uç nokta adresini değiştirebiliyorum. Sunucu taşındığında uygulamayı güncellemek gerekmiyor.

Bu yapılandırmayı çekerken iki şeye dikkat ediyorum: cevabı yerelde önbelleğe alıyorum (istek başarısız olursa uygulama açılmamazlık etmesin) ve varsayılan değerleri uygulamanın içine gömüyorum. İlk açılışta sunucuya ulaşamayan bir kullanıcı, boş bir ekran değil, makul varsayılanlarla çalışan bir uygulama görmeli.

Zorunlu güncelleme: gerekli ama tehlikeli

Yukarıdaki asgariSurum alanı, uygulamanın “bu sürümden eskisini artık çalıştırma” eşiği. Kullanıcının sürümü bunun altındaysa, kapatılamayan bir ekran gösterip mağazaya yönlendiriyorum.

Ama bu araç çok kolay kötüye kullanılıyor. Kullanıcıyı uygulamanın dışına atmak, elinizdeki en sert müdahale. Kendime koyduğum kural şu: zorunlu güncelleme sadece eski sürümün çalışmasının mümkün olmadığı durumlarda. Yani:

• Güvenlik açığı kapatıldıysa,
• Arka uç sözleşmesi geriye dönük uyumsuz şekilde değiştiyse,
• Eski sürüm veriyi bozuyorsa.

“Yeni tasarımı görsünler” zorunlu güncelleme sebebi değil. Onun için onerilenSurum alanı var: kapatılabilir, nazik bir hatırlatma gösteriyorum ve kullanıcı istediğinde devam edebiliyor.

Arka uç sözleşmesi: eski sürümü kırmamak

Mobilde en çok canımı yakan hataların çoğu, aslında sunucu tarafında yapılan “küçük” değişikliklerdi. Şu üç kuralı koyduktan sonra bu tür sorunlar bitti:

• Alan silmiyorum, eklemekle yetiniyorum. Bir alanı kaldırmam gerekiyorsa önce kullanılmaz hale getiriyorum, sahadaki sürümler yeterince azaldığında siliyorum.
• Alan tipini değiştirmiyorum. Sayı olan bir alanı metne çevirmek, eski ayrıştırıcıda çökmeye kadar gidebiliyor. Gerekiyorsa yeni adla yeni alan açıyorum.
• Kırıcı değişiklik gerekiyorsa yeni sürüm yolu açıyorum. /v3 yayında kalırken /v4 açılıyor; uygulamalar kendi hızlarında geçiyor.

İstemci tarafında da savunma yapıyorum: gelen JSON’da beklemediğim bir alan varsa yok sayıyorum, beklediğim bir alan yoksa varsayılana düşüyorum. Katı ayrıştırma, mobilde kırılganlık demek.

Sürüm numaralandırma ve sürüm notları

Sürüm numarasını anlamlı tutuyorum — büyük değişiklik, özellik, düzeltme sırasıyla. Bunun asıl faydası kullanıcıya değil bana: destek kutusuna “3.4.2’de çalışmıyor” diye bir mesaj geldiğinde, o sürümün ne zaman çıktığını ve neyi içerdiğini saniyede bulabiliyorum.

Sürüm notlarında “hata düzeltmeleri ve iyileştirmeler” yazmayı bıraktım. Kullanıcı o notu okuduğunda ne değiştiğini anlamalı. Somut yazmanın beklenmedik bir faydası daha var: bir sonraki sürüme kadar neyi düzeltmiş olduğumu kendim de hatırlıyorum.

Yayın öncesi kontrol listesi

Her sürümde aynı listeyi geçiyorum. Sıkıcı, ama unutulan tek madde dört günlük bir gecikmeye mal olabiliyor:

• Sürüm ve derleme numarası artırıldı mı
• Yayın (release) yapılandırmasıyla derlendi mi — hata ayıklama günlükleri kapalı mı
• Uç nokta adresleri canlıyı mı gösteriyor
• Yeni izin eklendiyse açıklama metni yazıldı mı
• Bir önceki sürümden güncelleyerek test edildi mi (temiz kurulum değil — güncelleme yolu)
• Yerel veritabanı şeması değiştiyse taşıma (migration) testi yapıldı mı
• Sürüm notları yazıldı mı
• Kademeli yayın açık mı

Bu listedeki en çok atlanan madde beşincisi. Temiz kurulumda çalışan bir sürüm, eski verinin üzerine geldiğinde çökebiliyor — ve sahadaki kullanıcıların neredeyse tamamı güncelleme yoluyla geliyor.

Özet

Mobil sürüm yönetiminin tamamı tek bir cümlede toplanabilir: geri alamayacağınız bir şey yayınlıyorsunuz, o yüzden geri alınabilir olan her şeyi dışarıda tutun. Kademeli yayın hatanın kaç kişiye ulaştığını sınırlıyor, sunucu tarafı anahtarlar hatayı yeni sürüm beklemeden kapatmanızı sağlıyor, geriye dönük uyumlu bir arka uç sözleşmesi de eski sürümlerin sizin yüzünüzden kırılmasını engelliyor. Üçü birden kurulduğunda yayın günü stresli bir gün olmaktan çıkıyor.

• Mobil Geliştirme
• Yayın Süreci
• App Store
• Google Play
• Mimari