Aynı nesneyi değiştiren birden çok özellik dalını kullanarak Flyway'i kullanma

Question

Bu konuya zaten çok sayıda soru ve yanıt var, örneğin, How to use Flyway when working with feature branches var, ancak hiç sahip olmadığım soru cevap vermiyor. Çözmesi bile mümkün olmayabilir.

ben basit saklı yordam olduğunu varsayalım:

CREATE PROCEDURE GetSomeData AS 
    SELECT Id, CreateDate, Stuff 
    FROM Data 

Şimdi, iki farklı özellik dallar oluşturulur ve her iki özellik aynı SP değiştirmesi gerekir. Özelliği A 20160414104532__limit_data.sql ilk değişim-komut dosyası oluşturur:

ALTER PROCEDURE GetSomData 
    SELECT Id, CreateDate, Stuff 
    FROM Data 
    WHERE CreateDate > DATEADD(day,-7,GETDATE()) 

Ve özellik B çıkışına bir sütun eklemek gerekiyor. Ancak farklı özellikler ile çalışan takımlar dünyanın farklı bölgelerinde yer alıyorlar ve birbirleri hakkında hiçbir şey bilmiyorlar. Bunlar 20160413153225__add_column.sql oluşturmak: özelliklerden biri tamamlandığında

ALTER PROCEDURE GetSomData 
    SELECT Id, CreateDate, Stuff, Things 
    FROM Data 

, üretim dalı haline birleştirilecektir. Üç hafta sonra, ikinci özellik tamamlandı ve üretime birleştirildi. Burada ikilem var, ikinci özellik ilk özellik tarafından değiştirilen saklı yordamın üzerine yazacak ve biz de üretimde bir hata yapabileceksiniz. Buradaki gerçek çözüm elbette prosedürü birleştirmektir, ancak senaryolar birbirinden bağımsız olduğu için, birleştirme sırasında bir çakışma belirtisi yoktur. Kötü bir şeylerin olduğunu öğrenmenin tek yolu, kodu çalıştırmak ve çalışma zamanında öğrenmek.

Bu tür sorunları bu süreçte daha önce bulmak için herhangi bir basit çözüm veya geçici çözüm var mı? Belki de bu tür ortamlarda kullanmak için uçağın aracı değil midir? Değilse, alternatifler nelerdir?

Answer 1

Bu sorunu, yinelenebilir geçişleri (merz tarafından önerildiği gibi) kullanarak çözdük. Çözümümüzün ardındaki fikir, düzenli geçişlerde tekrarlanabilir geçişler ve db şema geçişlerindeki "kod" geçişlerini tutmaktır. Saklı Usul (ve diğer klasörler) içindeki

Yapısı:: Projemizin kökünün

Yapısı

Her Saklı Yordam komut tanımını içermelidir yapılmış bir Kayıtlı Proc (burada SQL Server sözdizimi). Her komut dosyası üstündeki, tekrarlanabilir hale getirmek için, Saklı Proc (sadece CREATE OR alter olabilir diğer RDBMS) hemen sonra (varsa) düştü ve yeniden oluşturulur:

IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[MyStoredProc]') AND type in (N'P', N'PC')) 
DROP PROCEDURE [dbo].[MyStoredProc] 
GO 
SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 
CREATE PROCEDURE [dbo].[MyStoredProc] AS 
BEGIN 
    SET NOCOUNT ON; 

    SELECT 1 AS one; 
END 
GO 

Everytime bir geliştirici istiyor veritabanındaki bazı kodları düzenler, projemizdeki saklanmış proc ismindeki dosyada yapar. Daha sonra, uçağın göçü, projemizi her yönettiğimizde son sürüme geçmek için çalıştırılabilir (çünkü uçuş, sağlama toplamını değiştirdiğinde, tekrarlanabilir komut dosyasını yürütür). Tablo geçişleri için düzenli geçişler tutuyoruz çünkü tablo genellikle aşamalı olarak değiştirilebilir (ALTER TABLE dbo.MyTable ADD toplam INT NULL)

Git dallarını kullanırsak, kod farklılıklar arasında kolayca birleştirilebilir çünkü koddaki değişiklikler çatışma durumunda karşılaştırıldı ve çözüldü ve daha sonra aranan şubede birleştirildi.https://flywaydb.org/documentation/migration/repeatable - -

o