Hatalı sürüm telefona çoktan kuruldu
Dağıtım durdurulduğu hâlde müşteri sipariş gönderemiyor. Çünkü sorunlu sürüm zaten telefonunda. Yeni kurulumları yavaşlatmak ile kullanılabilir bir ürüne geri dönmek ayrı işler. Mobil yayın planının, mağaza onayından önce ikisini de anlatması gerekir.
Apple, kademeli dağıtımın duraklatılmasına izin veriyor; kullanıcılar bu sırada güncellemeyi elle indirebiliyor. Bu kontrol yayılımı sınırlamaya yarar, kurulu uygulamayı eski sürümle değiştirmez. Apple'ın dağıtım açıklaması bu ayrımı açıkça gösteriyor.
Mühendislik açısından tercihimiz, özellik konuşulurken kurtarma yolunun da belirlenmesi. Tek cevap yeni bir build göndermekse, ekip arada bozuk deneyimin devam edeceğini kabul etmiş demektir. Görsel bir kusur için bu kabul edilebilir. Sipariş, giriş veya çevrimdışı çalışma için aynı karar yeniden tartılmalı.
Kurulumu ve etkinleştirmeyi ayır
Bir özellik uygulamanın içinde bulunabilir ama herkese açık olmak zorunda değildir. Etkinleştirmeyi sorumlusu belli bir ürün kararı olarak tasarlamak gerekir. Kapatma anahtarı rastgele butonları gizlemek yerine anlamlı bir iş akışını yönetmeli.
Örnek olarak yeni bir belge tarama akışını düşünelim. Tarayıcı kapatıldığında mevcut dosya yükleme yolu geri gelmeli, yarım kalan belgeler korunmalı. Sadece gönder butonunu kaldıran bir flag, kullanıcıyı ilk hata kadar etkili biçimde kilitler.
Uzak yapılandırma alınamazsa hangi davranışın güvenli olduğu önceden seçilmeli. Hata kaydında uygulama sürümü yanında kullanılan yapılandırmanın kimliği de bulunmalı. Böylece destek ekibi telefonda hangi build olduğunu ve o build'in hangi davranışla çalıştığını ayırabilir. Kurtarma düğmesi arızalı servise bağımlıysa, planın zayıf noktası daha baştan bellidir.
Sunucu eski istemcileri de taşımalı
Ekip deploy yaptığında bütün müşteriler uygulamayı güncellemez. Desteklenen eski sürümler geçmişte kalmış dosyalar değil, servisin aktif istemcileridir. Backend değişikliğinde hangi isteklerin kabul edildiği ve eski istemcinin hangi cevap alanlarıyla karşılaşacağı açıklanmalı.
Yeni bir checkout tasarımında eski istemciyle sepet oluşturup yenisiyle açmayı deneyelim. Ardından tersini yapalım. Yarım işlemler de denemeye dâhil edilmeli; hatadan önce oluşan veri, onu oluşturan özellikten daha uzun yaşayabilir.
Geri döndürülemeyen bir veri değişikliği, doğru hazırlanmış feature flag'i etkisiz bırakabilir. Eski akış yeni kaydı okuyamıyorsa flag'i kapatmak sistemi geri getirmez. Kurtarma için gerekli bilgi korunmalı, eski veri gösteriminin ne zaman kaldırılacağı ayrı bir karar olmalı.
Olay anındaki kararı önceden yaz
Sürüm notu olay yönetim planı değildir. Dağıtımı hangi bulgunun durduracağı, kimin müdahale edeceği, müşteriye ne deneceği ve düzelmenin nasıl doğrulanacağı yazılmalı. Crash grafiği tek başına işin doğru tamamlandığını göstermez.
Tamamlanan işlemler ve destek kayıtları da izlenmeli. Sorunun hangi sürüm ve yapılandırmayı etkilediği anlaşılmalı. Özellik ortadan kaldırılınca hatanın kaybolması başarı sayılmaz; müşteri temel işini hâlâ yapabiliyor mu, buna bakılır.
Rahatsız edici maliyet, alternatif akışı yaşatmaktır. Onun da testi, sorumlusu ve kaldırılma zamanı olmalı. Bakılmayan eski akış sigorta değildir; acil durumda açılacak başka bir denenmemiş sürümdür.
Bu hafta yayından dönüşü prova et
Sıradaki özellik için dağıtımdan önce kurtarma sırasını yazalım. Hedef build'i kurup yarım iş oluşturalım, bağlantıyı keselim ve özelliği kapatalım. Hangi verinin kaldığını, müşterinin ne gördüğünü ve desteğin bu durumu nasıl tanıyacağını kontrol edelim.
Aynı provada desteklenen eski istemciyi yeni backend ile çalıştıralım. Geri alınamayan her geçişi kaydedip karar sahibini belirleyelim. Özelliği yazmayan bir ekip arkadaşı bu notu izleyerek tahminde bulunmadan kullanılabilir akışa dönebiliyorsa, yayın planının anlamı vardır.