Использование Flyway с несколькими функциональными ветвями, которые изменяют один и тот же объект

Есть уже несколько вопросов и ответов, касающихся этой темы, Как использовать Flyway при работе с ветвями функций, например, но ни один из них не отвечает на мой вопрос. Возможно, ее даже не удастся решить.

Допустим, у меня есть простая хранимая процедура: 

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

Теперь созданы две различные ветви функций, и обе функции должны изменить один и тот же SP. Функция а создает первый сценарий изменения, 20160414104532__limit_data.sql:

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

И функция B должна добавить a колонка к выходу. Однако команды, работающие с различными функциями, находятся в разных частях мира и на самом деле ничего не знают друг о друге. Они создают 20160413153225__add_column.sql: 

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

Когда одна из функций будет завершена, она будет объединена в производственную ветвь. Через три недели вторая функция была завершена и включена в производство. Вот дилемма, вторая функция перезапишет хранимую процедуру, которая была изменена первой функцией, и мы потенциально будет иметь ошибку в производстве.

Реальное решение здесь, конечно, заключается в слиянии процедуры, но поскольку сценарии независимы друг от друга, нет никаких признаков конфликта во время слияния. Единственный способ узнать, что случилось что-то плохое, - это запустить код и выяснить это во время выполнения.

Существуют ли какие-либо простые решения или обходные пути для поиска таких проблем ранее в процессе? Может быть, flyway не является инструментом для использования в таких видах окружающая среда? Если нет, то каковы альтернативы?

1 2
merge database database-migration

1 ответ:

Мы вроде как решили эту проблему, используя повторяющиеся миграции (как предложил Мерц). Идея нашего решения заключается в сохранении миграции "кода" в повторяющихся миграциях и миграции схемы БД в регулярных миграциях.

Структура корня нашего проекта:

Структура проекта

Структура внутри хранимых процедур (и других папок):

Папка хранимых процедур

Мы сделали так, чтобы каждый сценарий хранимой процедуры содержал определение одного сохраненного Proc (SQL Синтаксис сервера здесь). Чтобы сделать его повторяемым, в верхней части каждого скрипта сохраненный Proc отбрасывается (если он существует) и сразу же воссоздается (в других СУБД можно просто создать или изменить): 

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

Каждый раз, когда разработчик хочет отредактировать какой-либо код в базе данных, он делает это в файле, названном в честь сохраненного proc в нашем проекте. Затем flyway migrate можно запускать для перехода к последней версии каждый раз, когда мы git вытаскиваем наш проект (поскольку flyway выполняет повторяемый сценарий, когда он изменяется контрольная сумма). Для миграции таблиц мы сохраняем регулярные миграции, потому что таблицу обычно можно изменять постепенно (ALTER TABLE dbo.MyTable ADD total INT NULL)

Если мы используем ветви git, код может быть легко объединен между различными ветвями, потому что изменения в коде могут быть сопоставлены и разрешены в случае конфликтов, а затем объединены в нужной ветви.

Надеюсь, это поможет

2