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