Kod dalları arasında paylaşılan veritabanı şemalarıyla başa çıkmanın etkili yolları nelerdir?

Her bir dalın sonunda ana dalla birleştirildiği ve özünde yeni bir özellik geliştirmek için izole edildiği çoklu şubelere sahip bir proje üzerinde çalışmak.

MS SQL Server olan veritabanı paylaşılan bir şemaya sahiptir, ancak her dal ilerledikçe şemada değişiklik yapar.

Birincil araştırmam şemayı ana daldan türetilmiş şubeye kadar paylaşmanın iyi yollarıdır, böylece ana dalda yapılan değişiklikler türetilmiş yeni değişikliklere adım atmadan türetilmiş şubeye kolayca birleştirilir. dal?

Sürüm Denetiminde ve Veritabanınızda ayrıntılı olarak açıklanan aşağıdaki yöntemi başarıyla kullandım :

• meta verilerdeki sürüm numarasını koru (veritabanı genişletilmiş özelliği kullanıyorum)
• herhangi bir şema değişikliği geçerli sürümden sonraki sürüme güncellenen bir komut dosyası olarak kodlanır
• uygulama sürüm 0'dan (ilk dağıtım) güncel sürüme kadar yükseltmek için tüm komut dosyalarıyla birlikte gönderilir
• Her değişiklik bir senaryo ile yapılır. Sözlükler ve arama tablosu girişleri gibi 'sistem' veri değişiklikleri dahil.
• dağıtıldığında, uygulama diskteki şema sürümünü denetler, ardından şemayı geçerli gerekli sürüme getirmek için tüm yükseltme adımlarını çalıştırır

Sık sık 'bunun nesne tanımlama komut dosyalarını kaynak kontrolü altında tutmaktan nasıl farklı olduğu' fikrini duyuyorum. Fark çok büyük, çünkü uygulamanızın yeni bir sürümünü dağıttığınızda yeni bir veritabanı oluşturmayacaksınız. Çoğu zaman uygulamanızın , mevcut veriler de dahil olmak üzere mevcut veritabanını yükseltmesi gerekir . Bu önemli bir farktır, yükseltme adımlarınızın yükseltme sırasında mevcut verilerin bütünlüğünü ve tutarlılığını sağlaması gerekir. Bazı işlemler kod açısından önemsizdir (tablo nesnesi tanımlama komut dosyasına varsayılan değeri olan boş olmayan bir sütun ekleyin, tamamlandı), ancak gerçek dağıtımda aslında çok acı verici (tablo 1.5 Milyar satır içeriyor, ekleme sütunu tükenecek Eğer 'simpleton' yolu yapıldıysa günlük alanı).

Bu dallanma ile nasıl çalışır:

• şube oluşturulduğunda, geçerli şema sürümünü yakalar, örneğin sürüm 1.6
• ekip şube üzerinde çalışmaya başladığında 1.7 yeni bir sürüm ekler ve yükseltme adımını 1.6'dan 1.7'ye kodlamaya başlar.
• dalda değişiklikler yapıldıkça yükseltme adımı değişir. Her zaman v 1.6'dan 1.7'ye yükselen komut dosyasını çalıştırır, ancak tam olarak bu komut dosyalarının yaptıkları, daldaki normal kod yinelemelerine ve check-in'lerine tabidir
• şube geliştirmeyi bitirir, ters entegrasyona hazırlanır (taban çizgisine geri birleştirilir)
  • taban çizgisinden şubeye yeni bir ileri entegrasyon yapar. Entegrasyon şema versiyonunda herhangi bir değişiklik getirmezse, her şey iyidir, şube olduğu gibi entegre edebilir. 1.7 sürümü yeni temel sürüm olur.
  • ilginç olan şey, bu arada başka bir dalın tabana tersine entegre edilmesi ve şimdi temel şema versiyonunun 1.7 olarak değişmesidir. Bu durumda şubemiz, dağıtım hedefi şeması sürümünü 1.8'e çıkarmalı ve 1.7'den 1.8'e yükselterek yeni ortamda nasıl çalıştığını görmek için daha önce 1.6'dan 1.7'ye yükseltilen yükseltme adımını gözden geçirmelidir. Mantıksal şema çakışmaları çözülmeli, komut dosyası değişiklik gerektirebilir, sınama yapılmalıdır. Tamamlandığında, şube tabana tersine entegre olabilir. Ürünün konuşlandırılan hedef sürümü artık 1.8 oluyor.
  • şema sürüm 1.6 çatallı başka bir şube ters entegre etmek istediği zaman, şema sürümü 1.9 için çarpmak, 1.8 ila 1.9 arasında yükseltme komut dosyası test etmek gerekir, daha sonra tekrar tabana entegre edebilirsiniz gerekir.

Herhangi bir araç, sihirli şema farkı komut dosyası, sihirbaz ve sağ-düğme-tıklama-oluşturma-komut dosyası yok dikkat edin. Bu, kaynağa (komut dosyalarına) dayalı% 100 geliştirici odaklı bir işlemdir. Birçoğu tüm bu süreci ayrıntılı buluyor, ancak işe yarıyor. Aslında, bir SQL Server kullanıcısı olarak, SQL Server'ın günlük kullanımında bu işlemin sonuçlarını zaten kullandınız: SQL Server'ın kendisi çok benzer bir veritabanı yükseltme işlemi kullanıyor ve muhtemelen beklediğiniz gibi ürün geliştirme süreci geniş ölçüde yararlanıyor ve bahsettiğiniz sorun çözülmesi gereken çok gerçek bir sorundur.

BTW, dallanma / entegrasyonun gerçekte nasıl meydana geldiği, kaynak kontrol ürünleri arasında farklılık gösterir, performans entegrasyonu çalışma modundan tanıdık terimleri kullanıyorum .

Cevabım Remus kadar uzun olmasa da, bunun gerçekten iyi bir çözüm olduğunu gördüm. Henüz üretimde kurulmadı, bu yüzden YMMV *.

Liquibase

Temelde, XML dosyasında yeni öğeler olarak veritabanınızda şema değişiklikleri yaptığınız bir XML dosyasıdır. Örneğin:

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

Tamamen etli bir sözdizimine sahiptir, böylece veritabanınıza istediğiniz her şeyi yapabilirsiniz.

Ayrıca Liquibase kurulumunuzda hangi veritabanını sürümlendirmek istediğinizi de belirtirsiniz. Daha sonra .xml dosyasını dahil edilen Java yürütülebilir dosyasıyla (jar dosyası) "çalıştırırsınız". Bu, temel olarak XML'de belirtilen değişiklikleri veritabanınıza yeniden oluşturur.

Gerçek kicker, bu XML dosyasını kodunuzla aynı sürüm klasöründe depolamanızdır. Benim örneğimde bu Git'ti. Proje klasörümde (/.git ile aynı düzeyde) bu XML dosyası vardı ve sonra dalları değiştirdiğimde XML dosyası bu şube sürümüne değişecek ve .jar dosyasını çalıştıracak ve veritabanım şimdi bu dalı yansıtacaktır.

* Not: Java'yı SQL Server'a bağlarken sorun yaşadığım için uygulamayı tamamlamadım. Bazı jdbc sürücüleri ve böyle gerekiyor ve ben havasında değildi. Bu nedenle, kilometreniz değişebilir.

Red Gate'te yakında hem SQL Karşılaştırması hem de SQL Kaynak Denetimi'nden yararlanan bir veritabanı sürüm oluşturma çözümü yayınlayacağız. Bu, geçiş komut dosyaları yükseltme yaklaşımını kullanır ve veritabanını kaynak denetim revizyonuna karşılık gelen bir genişletilmiş özellik özelliğiyle damgalar.

Aralık ayının ortalarında serbest bırakılmayı umuyoruz. Şu anda bir sürüm adayı var. Daha fazla bilgi için şu adresi ziyaret edin:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

Önümüzdeki aylarda bu çözümü geliştirmeyi umuyoruz, bu yüzden lütfen ne düşündüğünüzü bize bildirin.

Siz ve şema değişikliklerinizi komut dosyaları oluşturarak ve bu komut dosyalarını kaynak denetimi altında tutarak, bu değişiklikleri diğer kodların birleştirdiği gibi ele alabilmeniz gerekir. Otomatik birleştirmeyi veya daha fazla manuel müdahale almayı seçebilirsiniz.

Canlı bir web sitesinde ve veritabanı şemasını değiştirmem gereken birkaç geliştirme dalında çalıştığım benzer bir durumdayım.

Git ile güzelce kullanılabilen bir post-checkout ve post-merge kanca yazarak çözdüm. Tüm geçişlerimi SQL dosyaları biçiminde ayrı bir dizinde saklıyorum ve değiştirilen PHP kodunun yanında taahhüt ediyorum. Her seferinde

git checkout

veya bir

git merge

git otomatik olarak uygun yukarı ve aşağı geçişleri çağırır. Github'daki uygulamamı görün .