Veritabanı dosyaları (komut dosyaları vb.) Kaynak kontrolünde olmalı mı? Eğer öyleyse, orada tutmak ve orada güncellemek için en iyi yöntem nedir?

Herkesin kullanabileceği ve gerektiğinde değişiklik yapabileceği bir geliştirme sunucusuna koyabileceğimizden, veritabanı dosyalarının kaynak kontrolü altında olmasına bile ihtiyaç var mı? Ama sonra birileri karışırsa geri alamayız.

Kaynak kontrolündeki veritabanları için en iyi hangi yaklaşım kullanılır?

Evet. Sisteminizin herhangi bir bölümünü veritabanı dahil olmak üzere kaynak kontrolünden yeniden oluşturabilmelisiniz (ve ayrıca belirli statik verileri de tartışabilirim).

Bunu yapmak için bir araç istemediğinizi varsayarak, aşağıdakileri dahil etmek istediğinizi öneririm:

• Şemalar, kullanıcılar, tablolar, anahtarlar, varsayılanlar ve benzeri dahil olmak üzere temel tablo yapıları için oluşturma komut dosyaları.
• Komut dosyalarını yükseltme (tablo yapısını değiştirerek veya verileri önceki şemadan yeni şemaya geçirme)
• Saklı yordamlar, dizinler, görünümler, tetikleyiciler için oluşturma komut dosyaları (doğru oluşturma komut dosyasında neyin bulunduğunun üzerine yazarken bunlar için yükseltme konusunda endişelenmenize gerek yok)
• Sistemin çalışmasını sağlamak için veri oluşturma komut dosyaları (tek bir kullanıcı, herhangi bir statik seçim listesi verisi, bu tür şeyler)

Tüm komut dosyaları uygun bırakma ifadelerini içermeli ve herhangi bir kullanıcı olarak çalıştırılabilmeleri için yazılmalıdır (böylece ilgili şema / sahip önekleri dahil).

Güncelleme / etiketleme / dallanma süreci tam olarak kaynak kodun geri kalanı gibi olmalıdır - bir veritabanı sürümünü bir uygulama sürümüyle ilişkilendiremezseniz, bunu yapmanın çok az noktası vardır.

Bu arada, insanların test sunucusunu sadece güncelleyebileceğini söylediğinizde, geliştirme sunucusunu kastetmenizi umuyorum. Geliştiriciler test sunucusunu hızlı bir şekilde güncelliyorsa, serbest bırakmak için neye ihtiyacınız olduğunu bulmak için acı dolu bir dünyaya bakıyorsunuz demektir.

Evet.

orada tutmak ve orada güncellemek için en iyi yöntem nedir?

Um. Bir şema oluşturucu komut dosyası yazın. Değişiklik yaptıktan sonra kontrol edin. Çalıştırmadan önce kontrol edin.

Ne istediğini belirlemek zor.

Resmi şema taşıma komut dosyaları yaz. Testten sonra kontrol ediniz. Çalıştırmadan önce onları kontrol edin.

Dahası ne var?

Olan şema değişikliklerinin büyük sorunlara dönüşmesidir, çünkü şema organik olarak bir dizi belgelenmemiş değişiklikle gelişir.

Bu organik evrim şema göçünü daha da zorlaştırıyor çünkü orada olması gerekenler için “yetkili” bir kaynak yok. İki farklı üretim sürümü, aşamalı bir versiyon, bir QA versiyonu ve sekiz geliştirme versiyonu var. Hepsi biraz farklı.

Tek, yetkili bir kaynak varsa, şema geçişi yalnızca son sürüm ile bu sürüm arasındaki deltadır.

Evet

Veritabanı komut dosyaları (ddl, dml) koddur. Tüm kodlar sürüm kontrol sisteminde bulunmalıdır.

Taşıma İşlemleri

• Veritabanı taşıma işlemlerini kullan

Geliştirme, qa ve bültenlerinde aynı db dosyalarını kullanmanıza izin verir.

• Bir sürüm numarasıyla veritabanına sürüm

Serbest bırakma numarasını denetlenecek bir yerde saklayın, çoğu db'de saklar. Her sürüm, veritabanını doğru sürüme ulaştırmak için geçişlerden oluşacak.

Veri tabanları için kaynak kontrolü sağlaması amaçlanan liquibase gibi araçlar vardır . Değişim / güncelleme komut dosyalarını, çoğu şirket gibi düzenli kaynak kontrol aracınızda tutmak zahmetlidir ve veritabanını her zaman sıfırdan başlatamazsınız.

Ayrıca bunu veritabanını karşılaştırma araçlarıyla (usta-müşteri db'yi karşılaştırın) karşılaştırarak otomatikleştirmeye çalıştık ve bu araçlara% 100 güvenmiyorsunuz, kesinlikle bir inceleme sürecine de ihtiyacınız var.

Evet

Ve dahası, dalları isteyeceksin .

Git'i dallar için kullanıyorum:

• özellik başına gelişme için (uygulamanın geri kalanının düzenli gelişimi için yaptığımız gibi)

• ve bir tane de üretim sunucusu için çünkü uygulamayı kullanan müşteriler de içerik yaratıyorlar.

Bu şekilde, hem kaynak kodlar hem de veritabanı (ve diğer dosyalarınız için) için kaynak kontrolünden ve dallanmadan yararlanırsınız.

Henüz bir all-in-one sistemi bulamadım [PostgreSQL için], bu yüzden şubeleri birleştirirken düzgün bir şekilde yeniden indekslemek için fonksiyonlar / komut dosyaları yazmak zorunda kaldım (örneğin, üretim dalındaki herhangi bir endeks değiştirilmemeli, çünkü müşteriler onlara güveniyorlardı) Üretim içeriğiyle kesişen geliştirme branşındaki indeksler + yabancı anahtarlar yeniden düzenlenmelidir: tüm uygulamalar için işe yaramaz, ancak uygulamamızın tüm durumlarını kapsar, bu nedenle yeterince iyidir).

Ancak genel fikir, veritabanı içeriğinin uygulamanın önemli bir parçası olduğu ve tüm kaynakların kaynak kontrolünde olması gerektiği , yani evet, veritabanı için kaynak kontrolünü kullanmanız gerektiğidir.

Java için ekibimiz kullanımı kolay ve güçlü bulduğumuz Flyway'i kullanıyor .

Ruby'de çalışıyorsanız, Rails'in bu sorunla baş etmenin de güçlü bir yolu olan Migrasyonları vardır.

Liquibase'den zaten bahsedilmiştir - bu iyi bir çözüm ama Flyway gibi alternatiflerden daha hantal buldum.

Ayrıca, RedGate yazılımı, SQL Server için tasarlanmış SQL Source Control adlı bir ürün sunar . Kendim kullanmadım, ama iş arkadaşlarımdan biri harika olduğunu söylüyor.

Geliştirme veritabanları üzerinde sürüm kontrolü veya değişiklik yönetimi olmadığı zaman, birçok kez gördüğüm problem bu. Programcı A tablo, görünüm veya işlemlerde değişiklik yapar. Programcı B de aynı şeyi değiştirir ve Programcı A'nın yaptıklarının üzerine yazar. Veya DBA, geliştirme veritabanını geliştirmeye geri yükler ve değişikliklerin üzerine yazar. Bu tür şeylerin kayda değer kedere neden olduğunu gördüm, çoğu zaman komik değildir. Ve bu sadece geliştirme sistemlerinde. Evreleme / test sırasında işler gerçekten karışabilir ve hatta üretim sunucuları buna yakalanabilir.

Veritabanı sürüm kontrolü, etkili olması için normal kod sürüm kontrolü ile aynı olmak zorunda değildir. Bununla birlikte, bir çeşit değişiklik kontrolü ve geçmiş yedeklemesi birçok sorunu önleyecektir.

Bunu "Kaynak Kontrolü" yerine "Sürüm Kontrolü" olarak düşünün. Bu, söz konusu komut dosyasının tüm geçmişini görebileceğiniz anlamına gelir. Veritabanını şu anki haliyle yeniden inşa edip edemeyeceğiniz, bu betikler ve bunları oluşturmak için kullanılan çerçeveler ile ilgili uygulamalarınızla ilgili olacaktır.

PHP / MySQL projelerimiz için Ladder adında (bir kez) küçük bir araç kullanıyoruz . Bir veritabanının zaman içindeki organik büyümesini kolaylaştırmak için tasarlanmıştır. Bir projeye ait tüm geçişler revizyon / kaynak / sürüm kontrolünde saklanır ve kodla birlikte izlenir.

Sütun eklemeyi / değiştirmeyi / bırakmayı, sorguları çalıştırmayı, indeksleri eklemeyi / bırakmayı, kısıtlamaları vb. Ayrıca, olması gereken bir göç belirterek "zamanda geri adım atmanıza" izin verir. ( php ladder.php migrate 15)

Oh, ve son ekleme veritabanı farklıdır. diff-saveKomutu çalıştırın, veritabanına bazı sütunlar ekleyin ve kaldırın ve diffkomutunu çalıştırın . Veritabanı durumuna bağlı olarak otomatik olarak oluşturulan geçiş kodunu göreceksiniz.

DataGrove , burada bahsedilen bazı problemleri çözer ( örneğin, jfrankcarr ).

Bir DB'deki tüm değişiklikleri izler ve tüm DB'nin durumunun bir sürümünü bir depoya kaydetmenize izin verir. Ardından, aynı DB'nin birden fazla sanal kopyasını oluşturmanıza olanak sağlar, böylece her geliştirici veya DBA kendi ayrı kopyasına sahip olabilir (her sanal kopya farklı bir sürümden oluşturulabilir). Kimsenin başkasının kodunu / değişikliklerini geçersiz kılmadığından emin olur. Sanal kopyaların her biri aynı depolarda izlenir, böylece tüm DB durumları kolayca paylaşılabilir ve yeniden oluşturulabilir.

Ayrıca veri sürüm aracı olarak da kullanılabilecek bir izleme aracı getirmeyi seveceğim. Bahsettiğim araç MONyog, aslında bir MySQL izleme aracıdır, ancak küçük bir kesimle kolayca veri sürümü olarak kullanabiliriz.

Ancak daha ileri gitmeden önce sürümlendirme için veritabanının tamamını koymak tavsiye edilmeyeceğini teklif edeceğim. Belirli bir veri kümesi için değişimi izlemek gerçek bir katildir.

MONyog, belirli veri kümesindeki değişikliği izleyebilen CSO (Özel SQL Nesneleri) adı verilen bir özelliğe sahiptir . Bir CSO eklemek burada açıklanmaktadır . Şimdi MONyog'un monitör geçmişi bölümünde, belirli bir süre içinde değişiklik yapabilirsiniz. En iyisi, html sayfasında görsel bir rapor verir. Rapor böyle bir şeye benzeyecek