Veritabanı değişikliği dağıtımlarını nasıl ele alırsınız?

Bugün veritabanı dağıtım tekniklerini tartışıyoruz, mevcut işlemimizde son zamanlarda birkaç başarısızlık yaşadık ve bir dağıtımı geri almak istediğimiz durumları gördük, ancak uygulamanın eski sürümü hiçbir zaman veri tabanı.

Bir yandan, sürüm yükseltme talimatınız ve sürüm düşürme talimatınız (ister SQL'de ister uygulama dilinizde yazılmış olsun) ve uygulamanızın hangi sürüme ulaşması gerektiğini bildiği Geçiş tarzı dağıtımlar vardır.

Bunlar basittir ve sık sık geri dönmeyeceğimiz için, geliştiriciler basitlere meraklıdır. Ancak, alan / tablo eklediğinizde riskler vardır ve geri dönmeden önce bu alan doldurulur. Ya da daha kötüsü, önceki sürümle ilgili verileri bıraktığınız yerde.

Öte yandan, geri almanın Göçler kadar sert olmadığı bir yükseltme, geri alma, ileriye doğru yaklaşımı düşünebiliriz. Örneğin, yükseltme boş bırakılamaz bir alan ekleyebilir; rollback, eski uygulamanın umursamaması için boş bırakılabilir yapar; rollforward null alanları doldurur ve tekrar boş bırakılamaz yapar.

Bu verileri korur ancak hem kodlamak hem de test etmek için karmaşıktır (ne yazık ki, otomatik entegrasyon testlerimiz hemen hemen yok ve bunu düzeltirken, bu arada bir sorunumuz var).

Bunlarla ilgili sorunları hafifletmenin güvenli yolları var mı? Dikkate almam gereken başka seçenekler var mı? Paylaşmak istediğin kötü deneyimler yaşadın mı?

Veritabanı değişiklikleri diğer tüm değişiklikler gibi ele alınmalı ve dağıtımın bir parçası olarak komut dosyaları olarak dağıtılmalıdır (ve elbette kaynak denetiminde saklanmalıdır). Aynı uygulama sürümünün koduyla dağıtıldıkları için, neyin geri alınması gerektiğini tam olarak bilirsiniz. Veritabanı betiğini yazdığınız sırada her değişikliği geri almak için süslü bir komut dosyası yazabilirsiniz, ancak geri almalar yaygın değilse, bunu yapmak istemeyebilirsiniz. Yeni bir sütun doldurulursa, orijinal veritabanına geri dönerseniz veri kaybedersiniz.

SQL Server'da, dağıtımdan hemen önce anlık görüntü alabilir ve dağıtım başarısız olursa hemen geri dönebilirsiniz. Bu, kullanıcılar sistemde olduğunda dağıtımın OLMADIĞINI varsayar (veri değişikliklerini kaybetmek istemezsiniz). Bu, büyük bir sürüm sırasında, yükseltmeyi yapmak için tüm sistemi geçici olarak almanız gerekebileceği durumlarda yararlıdır. Veya anlık görüntüyü alıp geri almanız gerekiyorsa farklılıkları görmek için anlık görüntü ile veritabanı arasında bir veritabanı karşılaştırması yapabilirsiniz. SQLCompare gibi bir araç, anlık görüntü yapısına geri dönmek için kodu bile oluşturabilir. Diğer veritabanları için neyin mevcut olduğunu bilmiyorum.

Bir veritabanı yapısındaki değişiklikler otomatikleştirilmeli / yazılmalı ve bir test ortamı kullanılarak test edilmelidir. Manuel değişiklikler üretim ortamında çok riskli

Tek makul geri alma stratejisi (işleri daha kötü hale getirme olasılığı en düşük olanı), bir yükseltme öncesi anlık görüntüye geri dönmektir. İşler yanlış gidecek olursa, anlık görüntüye geri dönmeyi yönetilebilir hale getirmek için yeterince hızlı veya geri alma için çok geç olacaktır (bir sonraki hafta sonu raporu, veritabanındaki sorunlar nedeniyle başarısız olur).

Değişiklikler kademeli olarak yapılabilir (alan eklemek gibi) ve bu yüzden hepsini tek geçişte yapmaktan daha az riskle canlı olarak test edilebilir.

Planlama ile, her sürümde yazılım ve veritabanı güncellemesiyle karşılaşmak yerine, gelecek sürümleri desteklemek için veritabanında değişiklikler yapabilirsiniz .

Bir veritabanı yükseltmesini izleyen günlerde, tıpkı bir yazılım yükseltmesi gibi acil durum modunda olmaya hazır olun .

Sorunları elle düzeltme dürtüsüne diren. Acil durum stratejinizi (geri alma, anlık görüntü) kullanın ve yükseltmeyi tekrar denemeden önce neden ters gittiğini düşünün.