Каковы эффективные способы работы со схемами баз данных, которые совместно используются ветвями кода?

Работа над проектом с несколькими ветвями, где каждая ветвь в конечном итоге объединяется с основной ветвью и по существу изолирована для разработки новой функции.

База данных MS SQL Server имеет общую схему, однако каждая ветвь вносит изменения в схему по мере ее развития.

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

Я успешно использовал следующую методологию, разработанную в системе контроля версий и вашей базе данных :

• поддерживать номер версии в метаданных (я использую расширенное свойство базы данных)
• любое изменение схемы кодируется как скрипт, который обновляется с текущей версии до следующей версии
• приложение поставляется со всеми сценариями для обновления с версии 0 (первоначальное развертывание) до текущей версии
• Каждое изменение выполняется через скрипт. Включая изменения системных данных, таких как словари и записи в таблицах поиска.
• после развертывания приложение проверяет версию схемы на диске, а затем выполняет все шаги по обновлению, чтобы привести схему к текущей требуемой версии.

Я часто слышу мнение «как это отличается от простого сохранения сценариев определения объектов под контролем исходного кода?». Разница огромна, потому что при развертывании новой версии вашего приложения вы не просто создадите новую базу данных. В большинстве случаев вашему приложению придется обновлять существующую базу данных, включая существующие данные . Это принципиальное отличие: ваши шаги по обновлению должны обеспечивать целостность и согласованность существующих данных во время обновления. Некоторые операции тривиальны в коде (добавьте необнуляемый столбец со значением по умолчанию в сценарий определения объекта таблицы, готово), но на самом деле они чрезвычайно болезненны при фактическом развертывании (таблица имеет 1,5 миллиарда строк, столбец добавления закончится пространства журнала, если сделано «простым способом»).

Как это работает с ветвлением:

• когда ветка создана, она привязывает текущую версию схемы, скажем, версию 1.6
• Когда команда начинает работать над веткой, она добавляет новую версию 1.7, а затем начинает кодирование шага обновления с 1.6 до 1.7.
• шаг обновления изменяется по мере внесения изменений в ветку. Он всегда запускает скрипт, который обновляется с версии 1.6 до 1.7, но то, что именно эти скрипты делают, подвержен обычным итерациям кода и проверкам в ветке
• ветвь заканчивает разработку, она готовится к обратной интеграции (для объединения обратно в базовую линию)
  • это делает новую прямую интеграцию от базовой линии до ветви. Если интеграция не вносит каких-либо изменений в версию схемы, все в порядке, ветка может выполнить обратную интеграцию как есть. версия 1.7 становится новой базовой версией.
  • Интересно, что в это время другая ветвь обратно интегрируется в базу, и теперь версия базовой схемы изменилась, скажем, на 1.7. В этом случае наша ветвь должна повысить версию своей целевой схемы развертывания до 1.8 и сделать обзор шага обновления, который ранее был с 1.6 до 1.7, чтобы увидеть, как он работает в новой среде, обновившись с 1.7 до 1.8. Конфликты логической схемы должны быть разрешены, сценарий может потребовать изменений, должно быть выполнено тестирование. После завершения ветвь может обратно интегрироваться в базу. Развернутая целевая версия продукта теперь становится 1.8.
  • когда другая ветвь, которая разветвилась в версии 1.6 схемы, хочет выполнить обратную интеграцию, ей необходимо повысить версию своей схемы до 1.9, протестировать скрипт обновления с 1.8 до 1.9, затем она может интегрироваться обратно в базу.

Обратите внимание, что здесь не задействован инструмент, нет сценариев различий с магической схемой, нет мастеров и не задействован скрипт, вызываемый правой кнопкой мыши. Это на 100% управляемый разработчиком процесс, основанный на источнике (скриптах). Многие находят этот процесс сложным, но он работает. Фактически, как пользователь SQL Server, вы уже использовали результаты этого процесса при ежедневном использовании SQL Server: сам SQL Server использует очень похожий процесс обновления базы данных, и, как вы, вероятно, ожидаете, процесс разработки продукта широко используется. ветвления и проблема, которую вы упомянули, является очень реальной проблемой, которая должна быть решена.

Кстати, то, как на самом деле происходит ветвление / интеграция, зависит от продуктов управления исходным кодом, я использую термины, знакомые по режиму работы Perforce integrate .

Хотя мой ответ может быть не таким длинным, как у Ремуса, я обнаружил, что это действительно хорошее решение. Я еще не настроил его на производство, так что YMMV *.

LiquiBase

По сути, это XML-файл, в котором вы вносите изменения в свою базу данных в виде новых элементов внутри XML-файла. Например:

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

Он имеет полностью продуманный синтаксис, поэтому вы можете делать все, что угодно, с вашей базой данных.

Вы также указываете в своей установке Liquibase, какую базу данных вы хотите создать для версий. Затем вы «запускаете» .xml с включенным исполняемым файлом Java (файл jar). Это по существу воссоздает те изменения, которые указаны в XML, в вашей базе данных.

Настоящим козырем является то, что вы храните этот XML-файл в той же версионной папке, что и ваш код. Так что в моем случае это был Git. У меня был этот XML-файл в папке моего проекта (того же уровня, что и /.git), и затем всякий раз, когда я переключал ветки, XML-файл менялся на эту версию ветки, и я запускал файл .jar, и моя база данных теперь отображала эту ветку.

* Примечание: я не закончил реализацию, потому что у меня были проблемы с подключением Java к SQL Server. Нуждаются в драйверах JDBC и так далее, и я был не в настроении. Следовательно, ваш пробег может варьироваться.

Здесь, в Red Gate, мы скоро выпустим решение для управления версиями базы данных, которое использует как SQL Compare, так и SQL Source Control. При этом используется подход обновления сценариев миграции и помечается база данных расширенным свойством версии, которое соответствует версии контроля версий.

Мы надеемся выпустить в середине декабря. Сейчас доступен кандидат на релиз. Для получения дополнительной информации посетите:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

Мы надеемся использовать это решение в ближайшие месяцы, поэтому, пожалуйста, дайте нам знать, что вы думаете.

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

Я нахожусь в аналогичной ситуации, когда я работаю над живым веб-сайтом и несколькими ветками разработки, в которых мне нужно изменить схему базы данных.

Я решил это, написав post-checkout и hook после слияния, которые можно использовать с git. Я храню все свои миграции в виде файлов SQL в отдельном каталоге и фиксирую их вместе с измененным кодом PHP. Каждый раз, когда я выполняю

git checkout

или

git merge

git автоматически вызовет соответствующие миграции вверх и вниз. Смотрите мою реализацию на Github .