Я бы не согласился с тем, что постепенные миграции являются гнилыми.На мой взгляд, наличие набора собственных сценариев было бы более плохим подходом, чем наличие реального инструмента для такой работы, который облегчит отслеживание этих изменений.Раньше мне приходилось сталкиваться с подобной ситуацией, поэтому, надеюсь, я смогу поделиться некоторыми идеями.
По моему опыту, RDBMS-схемы и ветви не очень хорошо сочетаются.В зависимости от вашего ветвления схемы должны быть, по крайней мере, несколько похожими, и в этом случае миграции не должны сильно отличаться.Или я мог просто неправильно понять всю проблему.Если вы, например, пытаетесь сохранить специфичный для клиента код в ветке, то, возможно, вам следует подумать о способе его модульности.Мы сделали что-то вроде этого, имея правила, которые утверждали, что специфическая для клиента схема меняется, и код может зависеть только от общей базы кода, а не наоборот.Мы также установили приоритет между сменами модулей на основе модуля и даты, поэтому мы в большинстве случаев знали порядок, в котором должны были применяться изменения.YMMV, конечно, но сложно дать конкретику, не зная ваших текущих настроек.
В моей старой компании мы успешно использовали инструмент под названием Liquibase , который звучит похоже на то, что вы используете.По сути, это инструмент для перевода схемы БД и всех данных из одного известного состояния в другое известное состояние.Тот же набор изменений применяется только один раз, поскольку liquibase ведет журнал изменений с контрольными суммами.Журналы изменений написаны в определенном формате XML.Я настоятельно рекомендую попробовать, если вам нужны альтернативы.
В любом случае, способ, которым мы обрабатывали код клиента и ветви, заключался в том, чтобы иметь конкретную базу данных / схему для данной ветви.Таким образом, вы можете получить схему и данные из точки ветвления и только перенести diff в текущую ситуацию.Мы не отменили изменения, даже если теоретически жидкость-база могла бы поддержать это, поскольку мы чувствовали, что это слишком громоздко и подвержено ошибкам.Принимая во внимание, что liquibase сохраняет свое собственное состояние, миграция всегда была такой же простой, как принятие текущего состояния в данной ветви и применение всего.Были применены только новые наборы изменений, в результате чего схема была в хорошем состоянии.
Мы использовали mercurial , который распространяется, как git, поэтому настройка была довольно схожей.У нас также были локальные базы данных для разработчиков на ноутбуках dev и ряд сред, как для разных заказчиков, так и для разных этапов (разработка, интеграция, производство), поэтому модель была подвергнута реальному тестированию, и она работала на удивление хорошо.У нас были некоторые конфликты в наборах изменений, но мы в основном смогли разрешить их вскоре после появления проблемы.Локальные envs разработки были действительно самой сложной частью, так как во время разработки, возможно, были внесены некоторые изменения схемы, которые не всегда были совместимы с более поздними наборами изменений, но структурированный характер изменений и наличие известного состояния, к которому можно вернуться, приводят к очень немногимреальные проблемы.
При таком подходе есть несколько предостережений:
- Все и любые изменения схемы должны быть реализованы в наборах изменений.Самой большой причиной растерянности всегда было то, что кто-то немного возился.
- Первый пункт также применим, даже если вы используете инструмент, который изменяет схему, например, ORM-инструмент, такой как Hibernate .Вы должны быть довольно близки с этим инструментом, чтобы понимать изменения, которые он вносит и требует.
- Все пользователи должны купить это и научиться следовать правилам.Проверка 1.
- Наступает момент, когда миграция лотов наборов изменений начинает занимать слишком много времени.В это время вам нужно будет создать новую базовую линию, которая может быть немного хитрой, особенно с большим количеством ветвей.Также хорошо планировать заранее и, по крайней мере, знать обо всех существующих ветвях БД.
- Вам нужно немного спланировать заранее с ветвями, чтобы знать, собираются ли они в какой-то момент вернуться обратно к мастеру.Наивное объединение может не сработать для изменений схемы.
- Для очень долгоживущих ветвей и отдельных наборов данных эта модель может быть недостаточно сильной
Суть, однако, в том, что чем больше у вас структуры и контроля над базой данных, тем легчемиграции будут.Поэтому такие инструменты, как Liquibase , могут быть очень ценным активом, чтобы помочь вам отслеживать эти изменения.Это относится к более сложным моделям даже в большей степени, чем к простым, поэтому, по крайней мере, не думайте о сбросе всех инструментов, которые у вас уже есть.И найдите время, чтобы изучить другие альтернативные инструменты.
Некоторая структура и управление лучше, чем ничего, или даже хуже, думая, что вы контролируете большую кучу ручных скриптов.