Geliştirme, test ve üretimdeki veritabanlarını nasıl yönetiyorsunuz?

Geliştirme, test ve üretim sunucuları arasındaki veritabanı şemalarını ve verileri yönetme konusunda iyi örnekler bulmaya çalışırken zorlandım.

İşte kurulumumuz. Her geliştiricinin, uygulamamızı ve MySQL veritabanını çalıştıran bir sanal makinesi vardır. İstedikleri her şeyi yapmak onların kişisel sanal alanıdır. Şu anda, geliştiriciler SQL şemasında bir değişiklik yapacak ve veritabanını SVN'de taahhüt ettikleri bir metin dosyasına dökeceklerdir.

Her zaman en son taahhüt edilen kodu çalıştıracak sürekli bir entegrasyon geliştirme sunucusu kurmak istiyoruz. Bunu şimdi yaparsak, her derleme için veritabanını SVN'den yeniden yükler.

"Sürüm adayları" nı çalıştıran bir test (sanal) sunucumuz var. Test sunucusuna dağıtım şu anda çok manuel bir işlemdir ve genellikle en son SQL'i SVN'den yüklememi ve ayarlamamı içerir. Ayrıca, test sunucusundaki veriler tutarsız. Son geliştiricinin sanal alan sunucusunda sahip olduğu test verileri ile sonuçlanırsınız.

Her şeyin bozulduğu yer, üretime dağıtımdır. Canlı verilerin test verileri ile üzerine yazamadığımız için, tüm şema değişikliklerinin manuel olarak yeniden oluşturulması gerekir. Verileri işlemek için çok sayıda şema değişikliği veya dönüşüm komut dosyası varsa, bu gerçekten kıllı olabilir.

Sorun yalnızca şema olsaydı, daha kolay bir sorun olurdu, ancak veritabanında güvenlik ve izin tablolarındaki meta veriler gibi geliştirme sırasında da güncellenen "temel" veriler var.

Bu, sürekli entegrasyona ve tek adımlı yapılara doğru ilerlerken gördüğüm en büyük engel. Nasıl mı sen bunu çözmek?

Takip eden bir soru: Belirli bir veritabanı örneğini yükseltmek için hangi komut dosyalarının çalıştırılacağını öğrenmek için veritabanı sürümlerini nasıl izlersiniz? Lance gibi bir versiyon tablosu standart prosedürün altında mı bahsediyor?

Tarantino'ya referansınız için teşekkürler. Bir .NET ortamında değilim, ancak kendi DataBaseChangeMangement wiki sayfasını çok yararlı buldum . Özellikle bu Powerpoint Sunumu (.ppt)

Ben *.sqlveritabanında bir tablo karşı belirli bir dizinde komut dosyalarının adlarını denetler ve dosya adının ilk bölümünü oluşturan bir tamsayı dayalı sırada olmayanları çalıştıran bir Python komut dosyası yazacağım . Oldukça basit bir çözümse, olacağından şüpheleniyorum, o zaman buraya göndereceğim.

Bunun için çalışan bir senaryom var. Varsa DB'nin başlatılmasını ve gerektiğinde yükseltme komut dosyalarının çalıştırılmasını sağlar. Varolan bir veritabanını silmek ve bir dosyadan test verilerini almak için de anahtarlar vardır. Yaklaşık 200 satır var, bu yüzden yayınlamayacağım (ilgi varsa macununa koyabilirim).

Birkaç iyi seçenek var. "Yedeklemeyi geri yükle" stratejisini kullanmazdım.

1. Tüm şema değişikliklerinizi komut dosyasılayın ve CI sunucunuzun bu komut dosyalarını veritabanında çalıştırmasını sağlayın. Geçerli veritabanı sürümünü takip etmek için bir sürüm tablosuna sahip olun ve komut dosyalarını yalnızca daha yeni bir sürüm için yürüttüklerinde çalıştırın.

2. Bir taşıma çözümü kullanın. Bu çözümler dile göre değişir, ancak .NET için Migrator.NET kullanıyorum. Bu, veritabanınızı sürümlendirmenize ve sürümler arasında yukarı ve aşağı hareket etmenize olanak tanır. Şemanız C # kodunda belirtilmiştir.

Geliştiricilerin, yalnızca tüm veritabanını kaynak denetimine dökmekle kalmayıp, üzerinde çalıştıkları her hata / özellik için değişiklik komut dosyaları (şema ve veri değişikliği) yazmalıdır. Bu komut dosyaları, mevcut üretim veritabanını geliştirme aşamasında yeni sürüme yükseltir.

Oluşturma işleminiz, üretim veritabanının bir kopyasını uygun bir ortama geri yükleyebilir ve veritabanındaki geçerli sürüme güncelleyecek tüm komut dosyalarını kaynak denetiminden çalıştırabilir. Tüm komut dosyalarının doğru çalıştığından emin olmak için bunu günlük olarak yapıyoruz.

Ruby on Rails'in bunu nasıl yaptığına bir göz atın.

Birincisi, temel olarak veritabanı şemasını ve verilerini sürüm N'den sürüm N + 1'e (veya sürüm N + 1'den N'ye düşürme durumunda) dönüştüren geçiş dosyaları olarak adlandırılır. Veritabanı geçerli sürümü söyleyen bir tablo var.

Test veritabanları, birim testlerinden önce her zaman temizlenir ve dosyalardan sabit verilerle doldurulur.

Veritabanlarını Yeniden Düzenleme: Evrimsel Veritabanı Tasarımı , veritabanının nasıl yönetileceği hakkında bazı fikirler verebilir. Kısa bir sürümü http://martinfowler.com/articles/evodb.html adresinden de okunabilir

Bir PHP + MySQL projesinde veritabanında saklanan veritabanı revizyon numarası vardı ve program veritabanına bağlandığında, önce revizyonu kontrol edecektir. Program farklı bir düzeltme gerektiriyorsa, veritabanını yükseltmek için bir sayfa açar. Her yükseltme, veritabanı şemasını değiştirecek ve mevcut tüm verileri geçirecek olan PHP kodunda belirtilmiştir.

• Veritabanlarınızı aşağıdaki gibi adlandırın - dev_<<db>> , tst_<<db>> , stg_<<db>> , prd_<<db>> (Açıkçası db isimlerini sabit kodlamamalısınız.
• Böylece aynı fiziksel sunucuda farklı tipte db'leri bile dağıtabilirsiniz (bunu önermiyorum, ancak ... kaynaklar sıkıysa)
• Verileri otomatik olarak bu veriler arasında taşıyabildiğinizden emin olun
• Db oluşturma komut dosyalarını popülasyondan ayırın = db'yi sıfırdan yeniden oluşturmak ve doldurmak her zaman mümkün olmalıdır (eski db sürümünden veya harici veri kaynağından)
• kodda sabit kod bağlantı dizeleri kullanmayın (yapılandırma dosyalarında olmasa bile) - dinamik olarak doldurduğunuz yapılandırma dosyaları bağlantı dizesi şablonlarında kullanın, yeniden derlenmesi gereken application_layer'ın her yeniden yapılandırması BAD
• veritabanı versiyonlama ve db nesneleri versiyonlama kullanın - Ödeyebileceğinizden hazır ürünler kullanın, eğer kendi başınıza bir şey geliştirmeyin
• her DDL değişikliğini izleyin ve bazı geçmiş tablolarına kaydedin ( örnek burada )
• GÜNLÜK yedekler! Bir yedeklemeden kaybolan bir şeyi ne kadar hızlı geri yükleyebileceğinizi test edin (otomatik geri yükleme komut dosyalarını kullanın
• DEV veritabanınız ve PROD'nuz bile aynı oluşturma komut dosyasına sahipseniz, verilerle ilgili sorunlarınız olacaktır, bu nedenle geliştiricilerin prod'un tam kopyasını oluşturmasına ve onunla oynamasına izin verin (bunun için eksileri alacağımı biliyorum, ancak zihniyet ve iş süreci, boklar fana vurduğunda size çok daha az mal olacak - bu yüzden kodlayıcıları ne yaparsa yapsın yasal olarak abonelik yapmaya zorlayın, ancak bunu sağlayın

Bu sürekli memnun olmadığım bir şey - bu soruna çözümümüz. Birkaç yıl boyunca her sürüm için ayrı bir değişiklik komut dosyası tuttuk. Bu komut dosyası, son üretim sürümündeki deltaları içerecektir. Uygulamanın her sürümünde, sürüm numarası aşağıdaki gibi bir şey vererek artar:

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

Bu, iki geliştirme çizgisini korumaya başlayana kadar yeterince işe yaradı: Yeni geliştirme için Trunk / Mainline ve hata düzeltmeleri için bir bakım dalı, kısa vadeli geliştirmeler, vb. Şüphesiz, daldaki şemada değişiklik yapma ihtiyacı doğdu. Bu noktada, zaten Bagajda dbChanges_n + 1.sql vardı, bu yüzden aşağıdaki gibi bir şema ile devam ettik:

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

Yine, bu yeterince iyi çalıştı, bir güne kadar ana hatta 42 delta komut dosyası ve dalda 10 tane gördük. ARGH!

Bu günlerde sadece bir delta betiği tutuyoruz ve SVN sürümüne izin veriyoruz - yani her sürümde betiğin üzerine yazıyoruz. Ve dallarda şema değişiklikleri yapmaktan kaçınırız.

Ben de bundan memnun değilim. Rails'ten göç kavramını gerçekten çok seviyorum. LiquiBase'den oldukça etkilendim . Artımlı veritabanı yeniden düzenleme kavramını destekler. Bir göz atmaya değer ve yakında ayrıntılı olarak bakacağım. Onunla deneyimi olan var mı? Sonuçlarınızı duymak çok isterdim.

Ayrıca , bir veritabanının çeşitli sürümleri arasındaki farkı kodlamak için SQL Compare gibi bir araç kullanmaya bakabilir , böylece sürümler arasında hızlı bir şekilde geçiş yapabilirsiniz

OP'ye çok benzer bir kurulumumuz var.

Geliştiriciler, özel DB'leri olan VM'lerde gelişir.

[Geliştiriciler yakında özel şubelere katılacaklar]

Test farklı makinelerde (aslında bir sunucuda barındırılan VM'lerde) gerçekleştirilir [Yakında Hudson CI sunucusu tarafından çalıştırılacaktır]

Referans dökümü db'ye yükleyerek test edin. Geliştiricilerin şema yamalarını uygulayın, ardından geliştiricilerin veri yamalarını uygulayın

Ardından birim ve sistem testlerini gerçekleştirin.

Üretim, müşterilere montajcı olarak dağıtılır.

Neler Yapıyoruz:

Korumalı alan DB'mizin bir şema dökümü alıyoruz. Sonra bir sql veri dökümü. Bunu önceki taban çizgisine göre ayırıyoruz. bu delta çifti n-1'i n'ye yükseltmektir.

dökümleri ve deltaları yapılandırıyoruz.

N CLEAN sürümünü kurmak için boş bir db'ye dökümü gerçekleştiriyoruz. Düzeltmek için araya giren yamaları uygulayın.

(Juha, Rail'in mevcut DB sürümünü kaydeden bir tabloya sahip olma fikrinden iyi olduğunu ve yükleme güncellemelerini daha az dolgun hale getirmesi gerektiğini söyledi.)

Beta testinden önce deltalar ve dökümler gözden geçirilmelidir. Geliştiriciler, kendileri için DB test hesapları eklemek gördüm gibi bu konuda herhangi bir yol göremiyorum.

Korkarım diğer posterlerle hemfikirim. Geliştiricilerin değişikliklerini yazmaları gerekir.

Birçok durumda basit bir ALTER TABLE çalışmaz, mevcut verileri de değiştirmeniz gerekir - geliştiricilerin hangi taşıma işlemlerinin gerekli olduğu hakkında bir şeyler yapmaları ve doğru şekilde yazıldıklarından emin olmaları gerekir (elbette bunu bir noktada dikkatlice test etmeniz gerekir serbest bırakma döngüsü).

Dahası, herhangi bir anlamınız varsa, geliştiricilerinizin değişiklikleri için geri alma komutları almasını sağlarsınız, böylece gerekirse geri döndürülebilirler. Geri dönüşlerinin sadece hatasız yürütülmesini sağlamakla kalmayıp aynı zamanda DB'yi daha önce olduğu gibi bıraktığından emin olmak için de test edilmelidir (bu her zaman mümkün veya arzu edilmez, ancak çoğu zaman iyi bir kuraldır) .

Bunu bir CI sunucusuna nasıl bağladığınızı bilmiyorum. Belki de CI sunucunuzun, her gece geri döndüğü ve o zamandan beri tüm değişiklikleri uyguladığı bilinen bir derleme anlık görüntüsüne sahip olması gerekir. Muhtemelen en iyisi, aksi takdirde kırık bir göç komut dosyası sadece o gecenin yapısını değil, takip edenleri bozar.

Check out dbdeploy , SQL dosya düzenleri ve şema sürümü tablo için kendi standartları takip ve piton sürümünü yazabilirsiniz, Java ve .net araçlar zaten mevcut bulunmaktadır.

Komut satırı mysql-diff kullanıyoruz : ALTER komut dosyası olarak iki veritabanı şeması (canlı DB veya komut dosyasından) arasında bir fark oluşturur. mysql-diff uygulama başlangıcında yürütülür ve şema değişirse geliştiriciye rapor verir. Bu nedenle geliştiricilerin ALTER'leri manuel olarak yazmaları gerekmez, şema güncellemeleri yarı otomatik olarak gerçekleşir.

.NET ortamındaysanız çözüm Tarantino'dur (arşivlenmiş) . Tüm bunları (yüklenecek sql betikleri dahil) bir NANT derlemesinde işler.

Ben ( Açık DBDiff içine çengel ) veritabanı şemaları karşılaştırarak bir araç yazdım ve size taşıma komut dosyaları önerecektir. Verileri silen veya değiştiren bir değişiklik yaparsanız, bir hata atar, ancak komut dosyası için bir öneri sağlar (örneğin, yeni şemada eksik olan bir sütun, sütunun yeniden adlandırılıp adlandırılmadığını kontrol eder ve xx oluşturur - oluşturur bir reame deyimi içeren script.sql.suggestion).

http://code.google.com/p/migrationscriptgenerator/ Korkarım sadece SQL Server :( Ayrıca oldukça alfa, ama ÇOK düşük sürtünme (özellikle Tarantino veya http://code.google ile birleştirirseniz) .com / p / simplescriptrunner / )

Bunu kullanmak için .sln bir SQL komut dosyaları projesi var. Ayrıca, değişikliklerinizi yerel olarak yaptığınız bir db_next veritabanınız da vardır (Management Studio veya NHibernate Schema Export veya LinqToSql CreateDatabase veya başka bir şey kullanarak). Sonra _dev ve _next DBs ile migrationscriptgenerator yürütmek, hangi oluşturur. geçiş yapmak için SQL güncelleme komut dosyaları.

Oracle veritabanı için oracle-ddl2svn araçlarını kullanıyoruz.

Bu araç bir sonraki işlemi otomatikleştirdi

1. her db şeması için şema ddls olsun
2. Sürüm kontrolü altına koy

manuel olarak çözülen durumlar arasındaki değişiklikler