Yeni sürümü canlıya alırken geri dönüş yolunu açık tutmak

Örnek bir iş senaryosu

Bir sitenin yeni HTML'i eski JavaScript dosyalarına başvuruyorsa sayfa açılır fakat düğmeler çalışmayabilir. Yayından önce bütün dosyalar yeni klasöre hazırlanmalı, temsilî sayfalar ve API akışı kontrol edilmelidir. Geçişten sonra HTTPS, yönlendirme, form kaydı ve yönetici erişimi gerçek alan adı üzerinden tekrar denenir. Önceki sürüm ihtiyaç halinde kullanılmak üzere korunur.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Statik site yayınında bile önbellek davranışı önemlidir. Yeni HTML farklı dosya adlarıyla üretilmiş JavaScript kaynaklarına başvuruyorsa eski dosyaları anında kaldırmak açık sekmelerde hata yaratabilir. Sürüm klasörlerini korumak ve içerik parmak izi taşıyan dosya adları kullanmak bu riski yönetmeye yardımcı olur. Dinamik API ayrı çalışıyorsa arayüz ile API sözleşmesinin uyumu kontrol edilmelidir. Yeni alan zorunlu hale getirilmeden eski istemcilerin davranışı düşünülmelidir. Yayın sonrası gözlem süresinde form hataları, bulunamayan kaynaklar ve sunucu günlükleri incelenmelidir. Geri dönüş kararı için hangi belirti ve hata oranının yeterli sayılacağı önceden yazılmalıdır.

Kontrolü kanıtla kapatma

Güvenlik ve yayın kontrolünde her madde için gözlenebilir bir sonuç belirleyin. “Giriş güvenli” demek yerine yetkisiz isteğin reddedildiğini, çıkış sonrası oturumun çalışmadığını veya çok büyük form gövdesinin kabul edilmediğini test edin. Sonuçları kullanılan sürüm ve tarih bilgisiyle kaydedin. Böylece daha sonraki değişikliklerde aynı davranış yeniden kontrol edilebilir. Test verileri gerçek müşteri verisinden ayrılmalıdır. Kayıt oluşturan testler sonrasında yalnızca test kayıtlarının temizlendiği doğrulanmalıdır. Başarılı kontrolün kapsamını açık tutun; birkaç test bütün sistemin kusursuz olduğunu göstermez.

Uygulama ile sunucu sorumluluklarını ayırın. Kod alan doğrulamasını yapabilir fakat dosya izinleri, sertifika bağlaması ve yedek erişimi sunucu düzeyinde doğru kurulmalıdır. Bir katmanın varlığı diğerini gereksiz hale getirmez. Kaynak dosyaları, yapılandırma sırları ve veritabanı herkese açık web klasörüne konulmamalıdır. Kullanıcıya gösterilen hata mesajı teknik ayrıntı veya gizli bilgi içermemeli; sunucu tarafındaki kayıt tanı koymaya yetecek kadar bilgi taşımalıdır. Yeni bir bileşen eklendiğinde saldırı yüzeyi ve bakım sorumluluğu da değerlendirilmelidir. Gereksiz özellikleri açık bırakmak sonraki kontrol yükünü artırır.

Kontrolleri tek seferlik teslim maddesi olarak görmeyin. Yeni sürüm, yeni entegrasyon veya yetki değişikliği bazı varsayımları geçersiz kılabilir. Düzenli bağımlılık taraması, erişim gözden geçirmesi ve geri dönüş denemesi planlayın. Otomatik taramanın bulgu vermemesi bütün açıkların bulunmuş olduğu anlamına gelmez. Kritik uygulamalarda kapsamlı bağımsız güvenlik değerlendirmesi ayrıca düşünülmelidir. Küçük bir işletme için başlangıçta en değerli adım çoğu zaman sorumlulukları ve kontrol takvimini netleştirmektir. Sertifika, yedek ve yönetici hesabı gibi temel bileşenlerin sahibi belli olduğunda sorunlar kişisel hafızaya daha az bağımlı kalır.

Ekibinize sorabileceğiniz sorular

• Önceki sürüm hazır mı?
• Derin bağlantılar doğrudan açılıyor mu?
• Form ve yönetim gerçek ortamda test edildi mi?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.