Müşterinin ilk oturumunda yürüyün
Yayınlamayı planladığınız ortamda yeni bir hesap oluşturun. Doğrulama ya da sağlayıcı geri çağrılarını izleyin, uygulamayı yeniden yükleyin, bir profili güncelleyin ve çıkış yapın. Yolculuğu klavye kullanarak dar bir ekranda tekrarlayın. Normal geliştirme oturumunuz eksik kurulum adımlarını ve bayat durumu gizleyebilir.
Sırada ne yapılacağını açıklayan mesajları kontrol edin. Boş bir ekran faydalı bir eylem sunmalıdır. Başarısız bir istek, işin başarılı olduğunu ima etmeden nasıl yeniden deneneceğini açıklamalıdır. Bu mesajlarda gerçek ürünün dilini kullanın ve hesap ile destek bağlantılarının gerçek hedeflere ulaştığından emin olun.
Yolculuğu her giriş yöntemi için bir kez tekrarlayın. Google ve GitHub için OAuth geri çağrılarının her biri kendi yönlendirme ve hata modlarını taşır (OAuth kurulum kılavuzu yapılandırmayı anlatır) ve sağlayıcının test izin ekranı, üretimdekinden farklı davranır.
- Yeni hesap oluşturma ve oturum geri yükleme çalışıyor.
- Çıkış, erişimi iptal eder ve önceki kullanıcının görünümünü temizler.
- Boş, yükleniyor ve hata durumları mobilde anlaşılır kalır.
- Her OAuth sağlayıcısı geri çağrısını gerçek alan adında tamamlar.
- Doğrulama ve sıfırlama e-postaları ulaşır, net okunur ve doğru ortama bağlanır.
- İlk çalıştırma deneyimi, yeni kullanıcıya sırada ne yapacağını söyler.
Ücretli erişimi sunucuda kanıtlayın
Ödeme kolay yarısıdır. Sağlayıcının sandbox'ında tüm yaşam döngüsünü yürüyün: satın alma, webhook alındı ve doğrulandı, yetkilendirme kalıcı, ücretli özellik açık — ardından yenileme, iptal ve iade. Her geçiş istemci bayrağı değil, sunucuya ait durumu değiştirmelidir. Faturalama kılavuzu supastack'in bu durumu nerede tuttuğunu gösterir.
Sonra görmeyi ummadığınız olayları test edin: iki kez teslim edilen bir webhook, başarısız bir ödeme, bir görevin ortasında sona eren bir abonelik. Yetkilendirme istek anında “bu şu anda izinli mi” sorusunu yanıtlar; panodaki bir rozet yanıtlamaz.
- Bir sandbox satın alması tamamlanır ve ücretli özelliği açar.
- Yinelenen webhook teslimatları güvenlidir — işleme idempotent'tir.
- İptal ve iade, erişimi sunucu sınırında geri alır.
- Sunuluyorsa koltuk başına ya da kullanım limitleri, koşullarının ötesini reddeder.
Sınırları gerçek bağımlılıklarla doğrulayın
Sahipliği doğrulamak için iki bağımsız hesap kullanın. Görev durumu ve kurtarma URL'leri dahil, bir hesabın kaydını diğer hesaptan almaya ve değiştirmeye çalışın. Ücretli erişimi yalnızca arayüzde bir düğmeyi gizleyerek değil, sunucu eylem sınırında kontrol edin.
Çalışma alanı kapsamlı kayıtlar çok kiracılı bir ürünün omurgasıdır — çalışma alanı sınırları yazısı modeli açıklar. Yığınınız ne olursa olsun lansman sorusu aynıdır: her okuma ve yazma, kanıt olarak kayıt kimliği ya da istemcinin gönderdiği çalışma alanı kabul edilmeden, sahipliği sunucunun kimliği doğrulanmış bağlamından mı türetiyor?
- Çalışma alanları arası okuma ve yazmalar reddedilir.
- Kurtarma ve görev URL'leri tek başına erişim vermez.
- Liste ve detay görünümleri aynı kapsamı uygular.
- Sunuluyorsa API anahtarları ve webhook'lar da çalışma alanı kapsamı taşır.
Hata yollarını bilerek uygulayın
Arka plan işi iki farklı şekilde başarısız olur ve her biri kendi testini ister. Başarısız bir gönderim, istemciyi bir şeyin kuyruğa alınıp alınmadığından emin olamaz halde bırakır — görev kapsamlı bir idempotency anahtarı ve kayıtlı bir gönderim, kurtarmanın isteği yinelemek yerine orijinali yeniden kullanmasını sağlar. Başarısız bir tamamlanma, işin çalıştığı ama sonucun asla ulaşmadığı anlamına gelir — yeniden denemeler ve durum sorgulaması bu boşluğu ikinci bir üretim olmadan kapatmalıdır.
Aynı düşünceyi sağlayıcılara da uygulayın: bir YZ sağlayıcı zaman aşımı, geri dönen bir e-posta, bir faturalama API hatası. Her biri sessiz bir yarım sonuç yerine belirli, açıklanabilir bir durumda bitmelidir. Görev kurtarma kılavuzu kitin üretim yolunun bunu nasıl ele aldığını belgeler.
- Gönderim zaman aşımı sonrası bir yeniden deneme, işi ya da maliyeti yinelemez.
- Başarısız bir tamamlanma görünür ve kurtarılabilir; sessiz bir kayıp değildir.
- Sağlayıcı hataları kullanıcıya genel çökmeler değil, dürüst durumlar olarak ulaşır.
İlk hataya hazırlanın
Birinin hatayı bulabildiğinden, ilgili göreve bağlayabildiğinden ve sağlayıcı gizli anahtarlarını açığa çıkarmadan kullanıcının kurtulmasına yardımcı olabildiğinden emin olun. Hangi günlüklerin ve denetim kayıtlarının var olduğunu, ne kadar sakladığınızı ve bir operatörün onlara nasıl eriştiğini doğrulayın.
Lansmandan önce “bir şeyler ters”in neye benzediğine karar verin: başarısız iş teslimatları, webhook doğrulama hataları, sağlayıcı harcamasında ani tırmanış. Kimsenin almadığı bir uyarı izleme değildir — gözlemlenebilirlik kurulumu bu sinyallerin bağlanmasını anlatır.
Yedekleri operasyonel bir alıştırma olarak ele alın: yapılandırılmış bir yedek, geri yüklenmiş bir yedekle aynı şey değildir. İhtiyaç duyacağınız günden önce, üretime benzeyen veriyle geri yüklemeyi bir kez çalıştırın.
- Bir hata, ona neden olan isteğe, kullanıcıya ve göreve izlenebilir.
- Günlüklerin ve denetim kayıtlarının bir sahibi, saklama politikası ve erişim kuralları vardır.
- Bir yedek yalnızca yapılandırılmamış, geri yüklenmiştir.
- Başarısız işler ve webhook hataları, bir insanın aldığı bir uyarı tetikler.
Ürünün etrafındaki yüzeyleri kontrol edin
Yasal ve iletişim yüzeyleri cilalama değil, lansmanın parçasıdır: ürünün gerçekte ne yaptığını anlatan gizlilik ve koşullar, bir insana ulaşan bir destek adresi ve işlemsel postanın sahip olduğunuz bir adresten gelmesi için doğrulanmış bir gönderen alan adı.
Her otomatik e-postayı bir müşteri gibi okuyun. Doğrulama, sıfırlama, makbuz ve tamamlanma mesajları ürünün adını, doğru ortama bağlantıları ve ölü bir noreply adresi olmayan bir yanıt yolu taşımalıdır.
- Gizlilik ve koşullar sayfaları, gerçekte çalıştırdığınız ürünü tarif eder.
- İşlemsel posta, sahip olduğunuz doğrulanmış bir alan adından gönderilir.
- Destek ve faturalama sorularının ulaşılabilir bir hedefi vardır.
Yayınlama ya da yayınlamama kararını açık hale getirin
Yayın kaydını bir araya getirin: derleme revizyonu, hedef ortam, neyin nasıl test edildiği ve neyin doğrulanmadan kaldığı. Dürüst boşlukları olan bir kontrol listesi, kendinden emin bir özeti yener — ilk vaka genellikle boşluklarda yaşar.
İhtiyaç duymadan önce geri alma yoluna karar verin: dağıtım nasıl geri alınır, arada yazılan veriye ne olur ve kararı kim verir. Sonra tamamen destekleyebileceğiniz en küçük teklif sürümünü yayınlayın ve bilinçli olarak genişletin.
Sık sorulan lansman soruları
Lansman kontrol listeleri öngörülebilir yerlerde başarısız olur. Çoğunu yakalayan sorular bunlardır.
- Çoğu SaaS lansmanı neyi unutur? — Akışların sonları: gerçekten iptal eden çıkış, erişimi gerçekten kaldıran iptal ve kâğıt üzerinde var olan yedek için bir geri yükleme tatbikatı.
- Kaç test hesabına ihtiyacım var? — Hedef ortamda en az iki. Veri yalıtımı ve davet akışları tek hesapla doğrulanamaz.
- Sandbox testi mi, üretim testi mi? — İkisi de. Sandbox yaşam döngüsü mantığını kanıtlar; küçük gerçek bir işlem anahtarların, alan adlarının ve webhook'ların doğru yere bağlandığını kanıtlar.
- Ne zaman yayınlamak güvenlidir? — Müşteri verisini ya da parasını koruyan her madde doğrulandığında ve doğrulanmamış maddeler sahipleriyle yazıldığında — özellik listesi tam göründüğünde değil.
- Lansmandan sonra ne değişir? — Yayın kaydını tutun, yapılandırdığınız hata uyarılarını izleyin ve auth, faturalama ya da kapsamda önemli her değişiklikten sonra kontrol listesini yeniden çalıştırın.