Данный текст явлется переводом. Оригинал по ссылке
Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему, стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно).
При подходе “Релизная ветка” вся новая работа происходит в trunk ветке репозитория. Как только продукт приближается к релизу, изменения схемы становятся более редкими и фризятся новые правки. В этот момент, команда создает ветку для релиза. Разработка нового функционала продолжается в транке с изменениями в схеме и всего остального кода. В ветку отправляются только фиксы ошибок. После релиза команда объединяет исправления с ветки в trunk.
Это достаточно сложный вопрос. Изменения схемы в ветке требуют постоянного внимания. Техника только вперед (forward-only, run-once), которую я использую при работе с ветками имеет ряд проблем. Над ними определённо предстоит подумать и вам при разработке вашего процесса миграции баз данных.
К примеру я знаю, что в моем процессе изменения схемы в ветке будут редкими. Если вы используете более агрессивную стратегию ветвления (как feature-branch), такой подход очевидно хорошо работать не будет. В отличие от других стратегий - типо Руби Миграций, которые могут легко продвигаться вперед или назад по изменениям (если вы только не делаете необратимых изменений). Как и в большинстве случаев в нашей отрасли, приходится искать компромиссы.
Скажем, команда подготовила базу данных на версии 01.00.0000, и написала 45 сценариев изменения в процессе разработки фич (01.00.0001 до 01.00.0045). Разработка нового функционала сделана, и продукт уже близок к релизу 1.0, поэтому создаём ветку 1.0 (примечание: версия продукта и версия базы данных не обязательно должны совпадать).
В точке ветвления, я создаю новый базис для базы данных. В этом случае, версия базиса 01.01.0000 или 02.00.0000 подходят прекрасно - я просто хочу, увеличить цифру старшего или младшего номера версии. Скажем, мы используем 02.00.0000 в целях продолжения обсуждения. Этот новый базис переходит в trunc. При новой установке базы данных (от транка) нужно просто запустить этот новый скрипт, так как он должен произвести ту же базу данных, что и исходный базис и в дополнение 45 скриптов изменения. Я также проверяю что папка с изменения схемы 02.00.0000 пуста, таким образом существующий базис базы данных забрал в себя этот код.
Теперь представьте, что команда работает дальше и создаёт 2 сценария изменения схемы в транке. Эти изменения 02.00.0001 и 02.00.0002. В этот момент ошибка обнаруживается на продакшене, и для её исправления требуется изменять схему. Sh#t!
Возвращаемся в ветку, команда создает изменения схемы 01.00.0046 и исправляет ошибку в сочетании с комбинацией кода и изменениями скрипта. Это хорошо для системы продакшена потому, что он получает только стабильную версию билда, так как эти базы данных никогда не видели скриптов изменения v2.0. Теперь мы можем просто обновить эту системы новой версией 1.0 сборки. Ветка сборки включает в себя и применит 46-й скрипт изменения. Теперь все хорошо, по крайней мере, в мире 1.0.
Что-бы добавить это исправление в trunc, есть два варианта решения. Ну, на самом деле существует бесконечное количество вариантов в зависимости от того, как применять ваши обновления, но здесь рассмотрим только два варианта:
С опции №1 вам стоит быть предельно осторожными. Потому что любая база данных, которая обновится до версии v2.0, не получит правки 46-й версии из ветки. Вы должны будете научить людей запускать этот скрипт вручную, или вам самим придётся пройтись и уничтожить все существующие базы данных v2.0 (которые на данный момент должны быть только на машинах разработчиков и машинах для тестирования). Это не самый лучший вариант, но если вы не зашли глубоко в 2.0 иногда этот подход можно назвать приемлемым.
Вариант №2 немного дружелюбнее. Базы данных v1.0 подберут исправление от 01.00.0046. Базы данных v2.0 подберут исправление от 02.00.0003. Вы должны быть осторожны при написании скрипта изменения 02.00.0003, так что-бы он не по-пытаться повторно применить изменения, если сценарий 01.00.0046 всё-таки был запущен ранее. Другими словами, на базах данных, установленные из скриптов базиса v2.0 необходимо применить скрипт 02.00.0003, но на базах данных продакшена, которые разрабатывались с версии 1.0, будут использовать скрипт 01.00.0046. Так как вы не хотите, чтобы 02.00.0003 создала ошибку путем добавления изменений, которые уже есть, при обновлении до версии 2.0.
Уфф, я надеюсь, что вы все это смогли понять. Ветки и изменения схемы всегда заставляют меня нервничать, но, к счастью, они встречаются редко. Даже тогда, когда они происходят, сценарии изменения обычно включают простые изменения и не похожи на большие изменений, которые вы видите в скриптах, написанных в процессе разработки нового функционала.
Цикл статей: