Стратегия ветвления для релиза на основе проекта БД - PullRequest
0 голосов
/ 23 декабря 2011

У нас есть проект asp.Net vb.net 2008 на tfs2010. Проект имеет одну основную ветвь, и для любого выпуска мы создаем новую ветвь функций, которая, наконец, развернута. После развертывания производства мы возвращаем филиал обратно в основной филиал.

Теперь мы также добавляем проект базы данных для управления нашим SQL. Вопрос в том, как управлять версиями дифференциальных скриптов. Проект db содержит все сценарии создания, что хорошо, если нам пришлось развернуть проект p с нуля, но проект уже запущен. Так что теперь любой новый выпуск или исправление обычно будет содержать сценарий изменения или изменения практически.

Есть идеи, как лучше всего управлять сценариями создания и сценариями изменений в каждом выпуске?

1 Ответ

0 голосов
/ 23 декабря 2011

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

Существует два типа сценариев обновления, которые мы применяем:изменения таблицы и изменения данных.

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

Этот подход требует дисциплины разработчика, но при правильной реализации мы смогли обновить базы данных, которые являются 4 основными ревизиями и 4 годами устарели.до текущей версии.

Для изменений данных мы используем инструменты из Красные Ворота , в частности Сравнение данных SQL .

Что касаетсяПрограммируемость базы данных (хранимые процедуры, триггеры и т. д.). Мы сохраняем один сценарий, который при выполнении удаляет все текущие элементы, а затем повторно добавляет текущие версии.Этот процесс включается с использованием строгого соглашения об именах для всех элементов программируемости (хранимые процедуры имеют имена, начинающиеся с s_prefix_, функции с fn_prefix_ и т. Д.).

Чтобы обеспечить применение правильных версий сценариев, мы добавили небольшие версиитаблица (обычно 1 строка), которая хранится в базе данных для записи текущей версии базы данных.Эта таблица обновляется сценарием обновления таблицы, когда она применяется.Мы также обновляем эту таблицу в сценарии, который применяется для создания базы данных с нуля.

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

В качестве примера:

Если предположить, что у нас есть две основные версии, 3 и 4, есть два сценария обновления update_v3.sql и update_v4.sql.У нас есть один сценарий начальной структуры tables.sql и один сценарий программируемости хранимой_программы.sql.Учитывая эти предположения, манифест будет выглядеть примерно так:

tables.sql> когда версия = 0 update_v3.sql> когда major_version <= 3 update_v4.sql> когда major_version <= 4 сохраненный_процесс.sql> всегда

Инструмент оценивает текущую версию и применяет сценарии в порядке, указанном в манифесте, чтобы гарантировать, что база данных всегда обновляется известным способом.

Надеюсь, это поможет вам получить некоторые идеи.

...