Veritabanınızı kaynak kontrolünden nasıl oluşturmalısınız?

SO topluluk wiki'sinde veritabanı nesnelerinin sürüm kontrollü olup olmayacağı konusunda bazı tartışmalar yapılmıştır. Ancak, veritabanı nesneleri için bir derleme otomasyon süreci oluşturmaya yönelik en iyi uygulamalar hakkında fazla tartışma görmedim.

Bu, ekibim için tartışmalı bir tartışma konusu oldu - özellikle geliştiriciler ve DBA'lar, veritabanı dağıtımına yönelik bir otomasyon yaklaşımının yararlarını ve risklerini değerlendirirken genellikle farklı hedeflere, yaklaşımlara ve endişelere sahip olduklarından.

SO topluluğundan gerçek dünyada hangi uygulamaların etkili olduğuna dair bazı fikirler duymak istiyorum.

Hangi uygulamaların gerçekten en iyisi olduğunun biraz öznel olduğunun farkındayım, ancak birçok insana hangi çalışmanın yararlı olabileceği hakkında iyi bir diyalog olduğunu düşünüyorum.

İşte bu konudaki ilgi alanlarıyla ilgili bazı teaser sorularım. Bunlar kesin bir liste değildir - daha çok insanların ne aradığımı anlamalarına yardımcı olacak bir başlangıç ​​noktasıdır.

1. Hem test hem de üretim ortamları kaynak kontrolünden mi oluşturulmalıdır?
   
   • Her ikisi de otomasyon kullanılarak mı oluşturulmalı yoksa kararlı, sonlandırılmış bir test ortamından nesneler kopyalayarak mı üretilmeli?
   • Dağıtım betiklerinde test ve üretim ortamları arasındaki olası farklılıkları nasıl ele alıyorsunuz?
   • Devreye alma komut dosyalarının testte olduğu kadar üretime karşı etkili bir şekilde çalışıp çalışmayacağını nasıl test edersiniz?
2. Ne tür nesneler sürüm kontrollü olmalıdır?
   • Yalnızca kod (prosedürler, paketler, tetikleyiciler, java vb.)?
   • Dizinler?
   • Kısıtlamalar?
   • Tablo Tanımları?
   • Tablo Değiştirme Komut Dosyaları? (ör. ALTER komut dosyaları)
   • Herşey?
3. Hangi tür nesneler sürüm kontrollü olmamalıdır?
   • Diziler mi?
   • Hibeler?
   • Kullanıcı hesapları?
4. SCM deponuzda veritabanı nesneleri nasıl düzenlenmelidir?
   • Dönüşüm komut dosyaları veya ALTER komut dosyaları gibi tek seferlik şeylerle nasıl başa çıkarsınız?
   • Veritabanından kaldırılan nesnelerle nasıl başa çıkarsınız?
   • Nesneleri geliştirmeden test seviyesine yükseltmekten kim sorumlu olmalıdır ?
   • Birden çok geliştiricinin yaptığı değişiklikleri nasıl koordine ediyorsunuz?
   • Birden çok sistem tarafından kullanılan veritabanı nesneleri için dallanma ile nasıl başa çıkarsınız?
5. Bu sürece, eğer varsa, makul olan istisnalar yapılabilir?
   • Güvenlik sorunları?
   • Kimlik gizliliği endişesi olan veriler?
   • Tam otomatikleştirilemeyen komut dosyaları?
6. Süreci nasıl esnek ve uygulanabilir hale getirebilirsiniz?
   • Geliştirici hatası mı?
   • Beklenmedik çevre sorunlarına mı?
   • Felaket kurtarma için mi?
7. Karar vericileri, DB-SCM'nin faydalarının maliyeti gerçekten haklı çıkardığına nasıl ikna edersiniz?
   • Anektodsal kanıt?
   • Sektör araştırması?
   • Sektördeki en iyi uygulama önerileri?
   • Tanınmış makamlara itiraz mı?
   • Maliyet fayda analizi?
8. Bu modelde veritabanı nesnelerine kim "sahip" olmalıdır?
   • Geliştiriciler?
   • DBA'lar?
   • Veri Analistleri?
   • Birden fazla?

İşte sorularınıza bazı cevaplar:

1. Hem test hem de üretim ortamları kaynak kontrolünden mi oluşturulmalıdır? EVET
   • Her ikisi de otomasyon kullanılarak mı oluşturulmalı yoksa kararlı, sonlandırılmış bir test ortamından nesneler kopyalayarak mı üretilmeli?
   • Her ikisi için de otomasyon. Ortamlar arasında veri kopyalamayın
   • Dağıtım betiklerinde test ve üretim ortamları arasındaki olası farklılıkları nasıl ele alıyorsunuz?
   • Aslında her ortam için farklı komut dizileri üretebilmeniz için şablonları kullanın (ör. Harici sistemlere, bağlantılı veritabanlarına, vb.)
   • Devreye alma komut dosyalarının testte olduğu kadar üretime karşı etkili bir şekilde çalışıp çalışmayacağını nasıl test edersiniz?
   • Bunları üretim öncesi ortamda test edersiniz: üretim ortamının tam kopyasında (veritabanı ve potansiyel olarak diğer sistemler) test dağıtımı
2. Ne tür nesneler sürüm kontrollü olmalıdır?
   • Yalnızca kod (prosedürler, paketler, tetikleyiciler, java vb.)?
   • Dizinler?
   • Kısıtlamalar?
   • Tablo Tanımları?
   • Tablo Değiştirme Komut Dosyaları? (ör. ALTER komut dosyaları)
   • Herşey?
   • Her şey ve:
     • Statik verileri (arama listeleri vb.) Unutmayın, böylece ortamlar arasında HERHANGİ bir veriyi kopyalamanıza gerek kalmaz.
     • Veritabanı komut dosyalarının yalnızca güncel sürümünü koruyun (tabii ki sürüm kontrollü) ve
     • ALTER komut dosyalarını saklayın: 1 BÜYÜK komut dosyası (veya beğenilen 001_AlterXXX.sql adlı komut dizini, böylece bunları doğal sıralama düzeninde çalıştırmak, sürüm A'dan B'ye yükseltilir)
3. Hangi tür nesneler sürüm kontrollü olmamalıdır?
   • Diziler mi?
   • Hibeler?
   • Kullanıcı hesapları?
   • bkz. 2. Kullanıcılarınız / rolleriniz (veya teknik kullanıcı adları) ortamlar arasında farklıysa, şablonları kullanarak yine de komut dosyası oluşturabilirsiniz (bkz. 1.)
4. SCM deponuzda veritabanı nesneleri nasıl düzenlenmelidir?
   • Dönüşüm komut dosyaları veya ALTER komut dosyaları gibi tek seferlik şeylerle nasıl başa çıkarsınız?
   • bkz. 2.
   • Veritabanından kaldırılan nesnelerle nasıl başa çıkarsınız?
   • DB'den silindi, kaynak kontrol bagajından / ucundan kaldırıldı
   • Nesneleri geliştirmeden test seviyesine yükseltmekten kim sorumlu olmalıdır?
   • geliştirme / test / yayın programı
   • Birden çok geliştiricinin yaptığı değişiklikleri nasıl koordine ediyorsunuz?
   • Her geliştirici için ayrı bir veritabanı OLUŞTURMAYIN. kaynak kontrolü kullanıyorsun, değil mi? bu durumda geliştiriciler veritabanını değiştirir ve komut dosyalarını iade eder. tamamen güvenli olmak için, gecelik derleme sırasında veritabanını komut dosyalarından yeniden oluşturun
   • Birden çok sistem tarafından kullanılan veritabanı nesneleri için dallanma ile nasıl başa çıkarsınız?
   • zor olan: ne pahasına olursa olsun kaçınmaya çalışın.
5. Bu sürece, eğer varsa, makul olan istisnalar yapılabilir?
   • Güvenlik sorunları?
   • test / üretim için şifreleri saklamayın. geliştirici için buna izin verebilirsiniz, özellikle günlük / gecelik DB yeniden oluşturmaları otomatik hale getirdiyseniz
   • Kimlik gizliliği endişesi olan veriler?
   • Tam otomatikleştirilemeyen komut dosyaları?
   • yayın bilgisi / ALTER komut dosyasıyla belgeleyin ve saklayın
6. Süreci nasıl esnek ve uygulanabilir hale getirebilirsiniz?
   • Geliştirici hatası mı?
   • sıfırdan günlük derleme ile test edilmiş ve sonuçları artımlı yükseltmeyle karşılaştırınız (ALTER kullanarak sürüm A'dan B'ye). hem ortaya çıkan şema hem de statik verileri karşılaştırın
   • Beklenmedik çevre sorunlarına mı?
   • sürüm kontrolü ve yedeklemeleri kullanın
   • PROD veritabanı şemasını, özellikle dağıtımdan önce düşündüğünüz şeyle karşılaştırın. SuperDuperCool DBA, bilet sisteminizde asla bulunmayan bir hatayı düzeltmiş olabilir :)
   • Felaket kurtarma için mi?
7. Karar vericileri, DB-SCM'nin faydalarının maliyeti gerçekten haklı çıkardığına nasıl ikna edersiniz?
   • Anektodsal kanıt?
   • Sektör araştırması?
   • Sektördeki en iyi uygulama önerileri?
   • Tanınmış makamlara itiraz mı?
   • Maliyet fayda analizi?
   • geliştiriciler ve DBA'lar kabul ederse, kimseyi ikna etmenize gerek yok, diye düşünüyorum ( MSSQL için dbGhost gibi bir yazılım satın almak için paraya ihtiyacınız yoksa )
8. Bu modelde veritabanı nesnelerine kim "sahip" olmalıdır?
   • Geliştiriciler?
   • DBA'lar?
   • Veri Analistleri?
   • Birden fazla?
   • Genellikle DBA'lar modeli onaylar (kod incelemesinin bir parçası olarak check-in öncesinde veya sonrasında). Kesinlikle performansla ilgili nesnelere sahipler. Ancak genel olarak takımın sahibi [ve tabii ki işveren :)]

Mümkün olduğunda SQL'i kaynak kodu olarak ele alıyorum

Standardın uyumlu SQL'inde yazabilirsem, genellikle kaynak kontrolümdeki bir dosyaya gider. Dosya, SP'ler, Table CREATE ifadeleri gibi mümkün olduğunca çok tanımlayacaktır.

Ayrıca kaynak kontrolünde test etmek için sahte verileri de dahil ediyorum:

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

Ve sonra tüm SQL sorgularımı soyutlayarak tüm projeyi MySQL, Oracle, MSSQL veya başka herhangi bir şey için oluşturabilirim.

Derleme ve test otomasyonu , uygulama kaynağı kadar önemli oldukları için bu derleme komut dosyalarını kullanır ve bütünlükten tetikleyicilere, prosedürlere ve günlüğe kadar her şeyi test eder.

TeamCity aracılığıyla sürekli entegrasyon kullanıyoruz. Kaynak kontrolüne yapılan her girişte, veritabanı ve tüm test verileri sıfırdan yeniden oluşturulur, ardından kod ve ardından birim testleri koda karşı çalıştırılır. CodeSmith gibi bir kod oluşturma aracı kullanıyorsanız, veri erişim katmanınızı her derlemeyle yeni oluşturmak için derleme sürecinize de yerleştirilebilir, böylece tüm katmanlarınızın "eşleştiğinden" ve nedeniyle hata üretmediğinden emin olun. uyumsuz SP parametreleri veya eksik sütunlar.

Her derlemenin, kaynak denetimindeki $ project \ SQL \ dizininde depolanan, sayısal bir önek atanan ve sırayla çalıştırılan kendi SQL betikleri koleksiyonu vardır. Bu şekilde, her derlemede dağıtım prosedürümüzü uyguluyoruz.

Arama tablosuna bağlı olarak, arama değerlerimizin çoğu komut dosyalarında saklanır ve yapılandırma verilerinin, örneğin "neden_kodları" veya "ülke_kodları" için beklediğimiz gibi olduğundan emin olmak için çalıştırılır. Bu şekilde, üretimde arama değerlerini değiştirmek için bir araç kullanmak yerine geliştiricide bir arama verisi değişikliği yapabilir, test edebilir ve ardından bunu kalite güvencesi ve üretim yoluyla "destekleyebilir" ve bu durum çalışma süresi için tehlikeli olabilir.

Ayrıca, üretime yönelik bir derlemenin başarısız olması durumunda veritabanı değişikliklerimizi geri alan bir dizi "geri alma" komut dosyası da oluşturuyoruz. Geri alma komut dosyalarını çalıştırarak test edebilir, ardından dağıtım komut dosyaları çalıştırıldıktan sonra sizinkinin altındaki bir sürüm için birim testlerini yeniden çalıştırabilirsiniz.

Liquibase için +1 : LiquiBase , veritabanı değişikliklerini izlemek, yönetmek ve uygulamak için açık kaynaklı (LGPL), veritabanından bağımsız bir kitaplıktır. Basit bir öncül üzerine inşa edilmiştir: Tüm veritabanı değişiklikleri (yapı ve veriler) XML tabanlı tanımlayıcı bir şekilde depolanır ve kaynak kontrolünde kontrol edilir. İyi nokta, DML değişikliklerinin yalnızca farklılık değil, anlamsal olarak depolanmasıdır, böylece değişikliklerin amacını izleyebilirsiniz.

Daha iyi etkileşim için GIT sürüm kontrolü ile birleştirilebilir . Bunu denemek için geliştirme ortamımızı yapılandıracağım.

Ayrıca , komut dosyalarından üretim kodu oluşturmak için Maven, Ant inşa sistemlerini kullanabilirsiniz .

Bu eksi, LiquiBase'in yaygın SQL IDE'lerine entegre olmaması ve temel işlemleri kendiniz yapmanız gerektiğidir.

Buna ek olarak kullanabilirsiniz ek olarak , DB testi için DBUnit'i- bu araç, veri oluşturma komut dosyalarının üretim ortamınızı sonradan temizleyerek test etmek için kullanılmasına olanak tanır.

BENİM NACİZANE FİKRİME GÖRE:

1. DML'yi dosyalarda saklayın, böylece sürümlerini oluşturabilirsiniz.
2. Kaynak kontrolünden şema oluşturma sürecini otomatikleştirin.
3. Test amacıyla geliştirici, derleme sistemi + yük testi Verileri komut dosyalarıyla veya DBUnit komut dosyalarıyla (Kaynak Kontrolünden) aracılığıyla kaynak kontrolünden derlenen yerel DB'yi kullanabilir.
4. LiquiBase, bağımlılıklara saygı duymak için komut dosyalarının "çalıştırma sırasını" sağlamanıza izin verir.
5. Üretimde kullanımdan önce ana brunch'ı TÜM değişikliklerle kontrol eden bir DBA ekibi olmalıdır. Demek istediğim, MASTER trunk'a girmeden önce diğer DBA'lardan gövde / dalı kontrol ediyorlar. Böylece usta her zaman tutarlı ve üretime hazırdır.

Faturalama üretim veritabanımızda kod değişiklikleri, birleştirme ve yeniden yazma ile ilgili tüm belirtilen sorunlarla karşılaştık. Bu konu, tüm bunları keşfetmek için harika.

"Teaser soruları" sorarak, birinin nihai cevaplar hakkındaki fikrinden çok bir tartışmaya ilgi duyuyorsunuz. Aktif (> 2500 üye) e-posta listesi olan AgileDatabases bu soruların çoğunu ele almıştır ve benim deneyimlerime göre bu tür tartışmalar için sofistike ve medeni bir forumdur.

Van'ın verdiği her cevaba temelde katılıyorum . Daha fazla içgörü için, veritabanı yönetimi için temel benim K.Scott Allen serisi (okunması gereken, IMHO. Ve Jeff'in görüşü de öyle görünüyor).

• Veritabanı nesneleri, tek bir SQL dosyası (diğer SQL dosyalarını çağırabilen) başlatılarak her zaman sıfırdan yeniden oluşturulabilir: Create.sql . Bu, statik veri eklemeyi içerebilir (listeler ...).
• SQL betikleri, düz dosyalarda ortama bağlı ve / veya hassas bilgiler saklanmayacak şekilde parametrelendirilir.
• Ben başlatmak için özel bir toplu iş dosyası kullanın Create.sql: Create.cmd. Amacı esas olarak ön koşulları (araçlar, ortam değişkenleri ...) kontrol etmek ve parametreleri SQL betiğine göndermektir. Ayrıca performans sorunları için CSV dosyalarından statik verileri toplu olarak yükleyebilir .
• Tipik olarak, sistem kullanıcısı kimlik bilgileri Create.cmddosyaya bir parametre olarak aktarılır .

IMHO, dinamik veri yükleme, ortamınıza bağlı olarak başka bir adım gerektirmelidir. Geliştiriciler veritabanlarını test, önemsiz veya hiç veri olmadan yüklemek isterken, diğer uçta üretim yöneticileri üretim verilerini yüklemek isteyeceklerdir. Test verilerini de kaynak kontrolünde depolamayı düşünürdüm (örneğin, birim testini kolaylaştırmak için).

Veritabanının ilk sürümü üretime sokulduktan sonra, yalnızca komut dosyaları oluşturmanıza (esas olarak geliştiriciler için), aynı zamanda komut dosyalarını da yükseltmenize (aynı ilkelere dayanarak) ihtiyacınız olacaktır:

• Veritabanından sürümü almanın bir yolu olmalıdır (bir saklı yordam kullanıyorum, ancak bir tablo da işe yarar).
• Yeni bir sürümü yayınlamadan önce, Upgrade.sqlN-1 sürümünün N sürümüne (N yayımlanmakta olan sürümdür) yükseltilmesine izin veren bir dosya (diğerlerini çağırabilen) oluşturuyorum. Bu betiği adlı bir klasör altında saklıyorumN-1 .
• Ben yükseltme yapan bir toplu iş dosyası var: Upgrade.cmd. Veritabanının geçerli sürümünü (CV) basit bir SELECT deyimi aracılığıyla alabilir Upgrade.sql, CVklasör altında depolanan komut dosyasını başlatabilir ve klasör bulunmayana kadar döngü yapabilir. Bu şekilde, örneğin N-3'ten N'ye otomatik olarak yükseltme yapabilirsiniz.

Bununla ilgili sorunlar:

• Veritabanı satıcılarına bağlı olarak veritabanı şemalarını otomatik olarak karşılaştırmak zordur. Bu, eksik yükseltme komut dosyalarına yol açabilir.
• Üretim ortamındaki her değişiklik (genellikle performans ayarı için DBA'lar tarafından) kaynak kontrolüne giden yolu bulmalıdır. Bundan emin olmak için, genellikle her değişikliği bir tetikleyici aracılığıyla veritabanına kaydetmek mümkündür. Bu günlük, her yükseltmeden sonra sıfırlanır.
• Daha ideal olarak, yine de, DBA tarafından başlatılan değişiklikler, mümkün olduğunda yayınlama / yükseltme sürecinin bir parçası olmalıdır.

Kaynak kontrolü altında ne tür veritabanı nesnelerine sahip olmak istiyorsunuz? Mümkün olduğunca çok şey söyleyebilirim, ama daha fazlasını değil ;-) Şifreli kullanıcılar oluşturmak istiyorsanız, onlara varsayılan bir şifre alın (oturum açma / oturum açma, birim testi amaçları için pratik) ve şifre değişikliğini manuel bir işlem yapın . Bu, şemaların aynı zamanda kullanıcı olduğu Oracle'da çok olur ...

Git sürüm kontrolünde MSSQL veritabanı ile Silverlight projemize sahibiz. En kolay yol, zayıflatılmış bir veritabanınız olduğundan emin olmak (içerik açısından) ve Visual Studio'dan eksiksiz bir döküm yapmaktır . Ardından, her bir dev makinesinde veritabanını yeniden oluşturmak için yapı komut dosyasından 'sqlcmd' yapabilirsiniz.

Dağıtım için bu mümkün değildir çünkü veritabanları çok büyüktür: bu, onları bir veritabanında bulundurmanın temel nedenidir.

Bir DB'nin kaynak kontrolünün ve büyük ölçüde oluşturma sürecinin bir parçası olması gerektiğine şiddetle inanıyorum. Kaynak denetimindeyse, C # 'da bir sınıf yazarken yaptığım gibi, SQL'de bir saklı yordam yazarken aynı kodlama güvenli korumalarına sahibim. Bunu, kaynak ağacımın altına bir DB betikleri dizini ekleyerek yapıyorum. Bu komut dosyası dizini, veritabanındaki bir nesne için mutlaka bir dosyaya sahip değildir. Bu bir baş belası olur! Veritabanımda sadece kod projemde yapacağım bir geliştiriyorum. Daha sonra kontrol etmeye hazır olduğumda, veritabanımın son sürümü ile üzerinde çalıştığım mevcut sürüm arasında bir fark yapıyorum. Bunun için SQL Compare'i kullanıyorum ve tüm değişikliklerin bir komut dosyasını oluşturuyor. Bu komut dosyası daha sonra belirli bir adlandırma kuralı ile db_update dizinime kaydedilir 1234_TasksCompletedInThisIteration burada numara zaten var olan komut dosyası kümesindeki bir sonraki sayıdır ve ad bu kontrolde ne yapıldığını açıklar. Bunu bu şekilde yapıyorum çünkü Derleme sürecimin bir parçası olarak, bu dizindeki betikleri kullanarak programlı olarak oluşturulmuş yeni bir veritabanıyla başlıyorum. İçeriğini çıplak db üzerinde çalıştıran her komut dosyası boyunca yinelenen özel bir NAnt görevi yazdım. Açıkçası, veritabanına girmek için bazı verilere ihtiyacım olursa, o zaman veri ekleme komut dosyalarım da var. Bunun da birçok faydası var. Birincisi, tüm eşyalarım değiştirildi. İkincisi, her yapı yeni bir yapıdır, bu da geliştirme sürecime giren sinsi şeyler olmayacağı anlamına gelir (sistemde tuhaflıklara neden olan kirli veriler gibi). Üçüncüsü, geliştirme ekibine yeni bir kişi eklendiğinde, yalnızca en yenisini almaları gerekir ve yerel geliştiricileri anında onlar için oluşturulur. Dördüncüsü, veritabanımın durumu her derlemede sıfırlandığı için (yani depolarımı, db).

Bu herkes için değil.

Bu her proje için değil. Genelde yeşil alan projeleri üzerinde çalışıyorum, bu da bana bu kolaylığı sağlıyor!

Beyaz kule tartışmalarına girmek yerine, işte benim için gerçek dünya sorunlarında çok işe yarayan bir çözüm.

Sıfırdan bir veritabanı oluşturmak, sql betiklerini yönetmek olarak özetlenebilir.

DBdeploy , bir veritabanının mevcut durumunu kontrol eden bir araçtır - örneğin, daha önce hangi komut dosyalarının ona karşı çalıştırıldığı, hangi komut dosyalarının çalıştırılabileceği ve dolayısıyla hangi komut dosyalarının çalıştırılması gerektiği.

Daha sonra gerekli tüm komut dosyalarını bir araya getirecek ve çalıştıracaktır. Daha sonra hangi komut dosyalarının çalıştırıldığını kaydeder.

En güzel araç ya da en karmaşık değil - ama dikkatli bir yönetim ile çok iyi çalışabilir. Açık kaynaklıdır ve kolayca genişletilebilir. Komut dosyalarının çalışması güzelce işlendikten sonra, en son komut dosyalarını kontrol eden ve belirli bir örneğe karşı dbdeploy'u çalıştıran bir kabuk komut dosyası gibi bazı ekstra bileşenler kolayca eklenebilir.

Burada iyi bir giriş görün:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Bunu bulabilirsiniz Liquibase aradığınız şeyin bir sürü işler.

Her geliştiricinin kendi yerel veritabanına sahip olması ve ekibe yayınlamak için kaynak kodu kontrolünü kullanması gerekir. Çözümüm burada: http://dbsourcetools.codeplex.com/ İyi eğlenceler, - Nathan