Mevcut sistemi güvenle değiştirin

Değişikliği çevreleyen sözleşmeleri belirleyin

Mevcut yazılımın çağıran bileşenleri, saklanmış verileri, zamanlanmış işleri ve işletim prosedürleri vardır. Bazı bağımlılıklar düzenlemek istediğiniz dosyada görünmez. Ajan yerelde doğru olan ama bu sözleşmelerden birini bozan değişiklik üretebilir.

Uygulamadan önce etkilenen verileri okuyan ve yazan bileşenleri belirleyin. Route’ları, arka plan işlerini, raporları ve dış entegrasyonları inceleyin. Başka ekiplerin veya eski istemci sürümlerinin mevcut davranışa bağımlı olup olmadığını kontrol edin.

Ajandan bu harita için kanıt göstermesini isteyin. Arama sonucu yararlı başlangıçtır, ancak dinamik çağrılar ve dış tüketiciler için sorumlunun bağımlılığı doğrulaması gerekebilir.

Mevcut davranışı gözlenebilir hâle getirin

İyi belgelenmemiş modülde sabit kalması gereken davranışın çevresine odaklı kontroller ekleyin. Bu kontroller mevcut sözleşmeyi anlatır. Mevcut her davranışın istenir olduğunu kanıtlamaz.

Mevcut davranış bir gereksinimle çelişiyorsa çelişkiyi kaydedin. Test kaydetti diye güvenlik kusurunu korumayın. Amaçlanan davranışı kusurdan ayırmak için gereken kararı alın.

Gerçekçi ve hassas olmayan test verileri kullanın. Ortaya çıkabilecek eski veri yapılarını ve eksik kayıtları ekleyin. Yalnızca yeni oluşturulan verilerle test edilen yeni şema, veri geçişi sorunlarını gizleyebilir.

Sürümler arasındaki geçişi inceleyin

customer_name alanının display_name olarak yeniden adlandırıldığı kurgusal durumu düşünün. Anında ad değişikliği dağıtım sırasında eski uygulama örneğini bozabilir. İki dosyayı tek pull request’te güncellemek dağıtımı atomik yapmaz.

Aşamalı yaklaşım uyumluluğu koruyabilir:

1. Eski alanı kaldırmadan yeni alanı ekleyin.
2. Yeni yazma işlemlerinin gereken değerleri nasıl tutarlı tutacağını tanımlayın.
3. Yeniden başlatılabilir süreçle mevcut kayıtları doldurun.
4. Tamlığı ve veriyi okuyan bileşenlerin davranışını doğrulayın.
5. Veriyi okuyan bileşenleri yeni alana geçirin.
6. Eski alanı ancak onu kullanan bileşenler kalmadığında kaldırın.

Tam yöntem veri tabanına ve yazma örüntülerine bağlıdır. İki yere yazma, işlemlerden biri başarısızsa tutarsızlık yaratabilir. Veri tabanı işlemi veya başka bir açık eşitleme yöntemi gerekebilir. Sistemin garantilerini kontrol etmeden bu örneği uygulamayın.

Martin Fowler bu genel geçişi parallel change, diğer adıyla expand-and-contract olarak açıklar. Temel fikir, kaldırmadan önce uyumlu geçiş sağlamaktır.

Kurtarmayı rollback’ten ayrı planlayın

Kod rollback’i önceki uygulama sürümünü geri getirir. Veri geçişini otomatik olarak geri almaz. Eski sürüm yeni veriyi anlamayabilir. Yıkıcı bir geçiş, kod rollback’inin kurtaramayacağı bilgileri kaldırabilir.

Her adım için kurtarma işlemini belirleyin. Yeniden başlatılabilir veri doldurma sürecini sürdürmek güvenli olabilir. Yanlış dönüşüm, korunmuş kaynak verilerden düzeltme gerektirebilir. Yıkıcı işlem doğrulanmış geri yükleme prosedürü gerektirebilir.

Kurtarma kararından kimin sorumlu olduğunu ve ne kadar sürebileceğini sorun. ‘Yedeklerimiz var’ ifadesini kurtarmanın hizmet gereksinimini karşıladığının kanıtı olarak görmeyin.

Değişikliği incelenebilir tutun

İlgisiz temizliği işlevsel değişiklikten ayırın. Pull request’te uyumluluk planını, doğrulama sonuçlarını ve kaldırma koşullarını verin. Rollback’in ek iş gerektirmeye başladığı noktayı işaretleyin.

Ajan tüketicileri incelemeye ve geçiş kodunu hazırlamaya yardımcı olabilir. Yetkili sorumlu yine de geçiş ve kurtarma planını kabul etmelidir. Son tasarım, güvenli değişikliğin yalnızca bir bölümüdür.