Veri

EF Migrations: Runtime yerine EF bundle ile güvenli dağıtım

Bu yazı, EF Core şemasını uygulama başlangıcında MigrateAsync() ile değiştirmenin neden riskli olduğunu ve bunun yerine EF bundle'ların CI adımı olarak nasıl kullanılacağını anlatıyor. Yazar, ne zaman çalışma zamanı migration'ının kabul edilebilir olduğunu da ayırıyor. Migration'ları dağıtım kimliğiyle ayırmak isteyen ekipler için pratik bir rehber.

Mostly Lucid (Scott Galloway) Scott Galloway
Yayın tarihi
Okuma süresi
19 dk okuma
agent çalıştırması #14
agent çalıştırması #14
Orijinale git mostlylucid.net

Bu haberi bildir

Özette bir hata mı var, ya da bu içeriğin sahibi misin? Mesajın doğrudan bana e-posta olarak gelir.

Mesaj türü

Kilit noktalar

  • Üretimde MigrateAsync() yerine, şema değiştiren ayrı bir dağıtım kimliğiyle çalışan EF bundle kullanın.
  • Bundle'ı dotnet ef migrations bundle ile üretin; --self-contained ve --target-runtime hedef platforma göre seçilmeli.
  • Bundle'da --dry-run yok; önce dotnet ef migrations script ile SQL üretip gerçek veriye yakın bir kopyada test edin.
  • Aynı test edilmiş artefaktı test, staging ve production arasında taşıyın ve dağıtım işini korumalı bir ortama bağlayın.
  • Yerel bundle'larda ./efbundle --connection ile bağlantı dizesini açıkça verin.
  • Bundle geri alma stratejisi değildir; yayınlanmış migration'lar için yeni bir düzeltici migration tercih edin.

Çalışma zamanında MigrateAsync() çağırmak, uygulamanın başlangıcını veritabanı şeması değişikliğine bağlar ve uygulamaya şema değiştirme yetkisi verir. Yazar, kendi kişisel blogunda bu yaklaşımı bilerek kullandığını, ancak çoklu örnek, hassas veri veya gerçek kullanıcılı üretim ortamlarında bunun uygun olmadığını söylüyor. Önerilen alternatif EF bundle: derlenmiş migration'ları içeren çalıştırılabilir bir dosya. CI'da üretilip korumalı bir ortam adımında ayrı bir dağıtım kimliğiyle çalıştırılıyor.

Bundle'lar ayrıca migration geçmişini takip eder, hatalar pipeline loglarında görünür ve sürüm kontrolüne alınan aynı artefakt test, staging ve üretim arasında taşınabilir. Yazı, bundle'ın bir dry-run modu olmadığını, bunun yerine migrations script ile SQL üretilmesi ve gerçek veriye yakın bir kopyada test edilmesi gerektiğini vurguluyor. Ayrıca SQL script, DACPAC ve yerel test iş akışları için ayrıntılı örnekler içeriyor.

Gerçek dünyada kullanımı

  • Birden fazla replika çalıştıran ve kullanıcı verisi tutan bir ASP.NET Core API için şema değişikliğini ayrı bir CI/CD adımına taşımak.
  • Şemayı DBA'nın inceleyeceği bir ortamda, bundle veya SQL script çıktısıyla değişiklik onayı almak.
  • Yerel geliştirmede hızlı iterasyon yaparken, üretim için aynı migration'ları bundle ile test etmek.

Neden önemli

Uygulamanızın başlangıç yetkisini düşürmek ve şema değişikliğini kontrollü bir dağıtım adımına almak, üretimde kesinti ve güvenlik riskini azaltır. Bundle'ın dry-run olmadığını bilmek, değişiklikleri gerçek veriye yakın bir ortamda test etmeyi zorunlu kılar.

Bu özet, Mostly Lucid (Scott Galloway) üzerindeki orijinal yazıdan agent tarafından üretildi. Yazının tamamı ve tüm hakları ilgili yazara/yayıncıya aittir. Orijinal yazıya git

Benzer haberler

Geri bildirim

Bir hata mı buldun, bir fikrin mi var? Yazdığın mesaj doğrudan bana e-posta olarak gelir.

Mesaj türü