Veritabanı değişikliği içeren yazılım sürümünü hazırlamak
Koda geri dönmek, değişmiş veritabanıyla uyumu kendiliğinden sağlamaz. Tam bir test örneği, geçişte ve dönüşte nelerin kontrol edileceğini gösteriyor.
Yazılım sürümü geçişinde uygulama ve veritabanı bazen birlikte değişir. Bu nedenle dönüş yolu, önceki program sürümünden fazlasını dikkate almalıdır. Hangi kod, yapılandırma ve veri yapısının birlikte çalıştığını kaydedin.
Aşağıdaki varsayımsal portal örneği planlanan bir testtir. Gerçek müşteri veritabanında değişiklik anlatmıyor.
Dönüşü aynı veri durumunda sınayın
Mevcut V1 uygulaması müşteri adlarını customer_name alanından okuyor. Yeni V2 uygulamasının display_name alanını okuması planlanıyor. İlk düşünülen akışta eski sütun kaldırılıyor. Ardından yeni uygulama eksik yapılandırma nedeniyle başlamıyor.
Adım | Adımdan sonra veritabanı | Örnekteki sonuç |
|---|---|---|
Geçişten önce | Eski ad sütunu mevcut | Mevcut uygulama çalışır |
Planlanan değişiklikten sonra | Yalnız yeni ad sütunu mevcut | Yeni uygulama yapılandırma nedeniyle başlamaz |
Yalnız eski kodu yeniden devreye alma | Yine yalnız yeni ad sütunu mevcut | Eski uygulama beklediği sütunu bulamaz |
Eski kodu yeniden devreye almak veri yapısını geri döndürmez. Dağıtım aracındaki geri dönüş düğmesi bu uyumsuzluğu kendiliğinden çözmez.
Uyumlu bir geçiş planlayın
Olası bir alternatif aşamalı geçiştir: Önce eski sütun korunur ve yenisi eklenir. Mevcut değerler izlenebilir şekilde taşınır. Ekip hangi alanın esas olduğunu ve geçiş sırasında değişikliklerin nasıl tutarlı kalacağını belirler.
Ayrı test ortamında iki uygulama sürümü de bu ara veri yapısıyla sınanır. Bir adı değiştirip iki sürümden de doğru okumak buna dahildir. Sonraki değerler yalnız bir alana yazılıyorsa tek seferlik kopyalama yetmez.
Geçiş doğrulandığında ve eski sürüme artık dönüş yolu olarak ihtiyaç kalmadığında eski alanın kaldırılması planlanır. Bu, hangi eski sürümlerin hâlâ kullanılabileceğini yeniden değiştirir. Adım için ayrı karar gerekir.
Geçişten sonraki veriyi de düşünün
Eski bir yedek önceki yapıyı içerebilir. Bu sırada yeni siparişler alındıysa yedekte bulunmayabilirler. Geri yükleme bu işlemleri fark ettirmeden silmemeli. Sonradan hangi verilerin geldiği ve nasıl uzlaştırılacağı kurtarma planına dahildir.
Değişikliğe göre planlı bakım aralığı veya yeni sürümde hedefli bir düzeltme daha uygun olabilir. Aşamalı geçiş, kesintisiz güncelleme için genel bir söz değildir.
Denemenin sonucunu kaydedin
Sınanmış sürümü, yapılandırmayı, veri durumunu ve başarısızlıkta karar verecek kişiyi belgeleyin. Testte bir siparişi hedefte doğrulanmasına kadar izletin, sonra planlanan dönüşü uygulayın. Hangi verilerin korunduğunu ve hangi kısıtların bulunduğunu yazın.
Böylece canlı geçişten önce dönüş yolunun uygulamayla ve verileriyle gerçekten uyuşup uyuşmadığı görünür olur.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile Bulut ve işletim
Barındırma, yayına alma, bakım ve destek