управление версиями баз данных Sql Server в больших группах

Question

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

Мы используем Tortoise SVN и храним все репозитории на собственном выделенном сервере. Некоторые клиенты требуют, чтобы мы не хранили свои реальные данные на наших офисных серверах, поэтому мы храним только сценарии, которые могут генерировать структуру их базы данных, вместе со сценариями для создания полезных поддельных данных. В других случаях наши клиенты хотят, чтобы мы имели самую последнюю информацию о наших машинах для разработки.

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

1. Сохраняйте сценарии для каждой базы данных в SVN и заставляйте разработчиков экспортировать новые сценарии, если они вносят даже незначительные изменения
2. Отключение баз данных после внесения изменений и фиксация MDF-файла в SVN
3. Поместите все копии для разработки на сервер в собственной сети и заставьте разработчиков подключаться через удаленный рабочий стол для внесения изменений
4. Какой-то другой вариант, о котором я не думал

Answer 1

Никогда не имейте MDF-файл в дереве исходного кода разработки. MDF - это результат развертывания приложения, а не части его источников. Мышление в базе данных с точки зрения источника разработки является кратчайшим путем в ад.

Все результаты разработки должны быть сценариями, которые развертывают или обновляют базу данных. Любое изменение, независимо от того, насколько оно мало, принимает форму сценария. Некоторые рекомендуют использовать инструменты сравнения, но я думаю, что они - крысиная нора. Я отстаиваю версию метаданных базы данных и наличие сценариев для обновления с версии N до версии N + 1. При развертывании приложение может проверить текущую развернутую версию, а затем запускает все сценарии обновления, которые переводят версию в текущую. Нет сценария для непосредственного развертывания текущей версии, новое развертывание развертывает сначала v0 базы данных, затем проходит все обновления версии, включая удаление объекта, который больше не используется. Хотя это может показаться немного экстремальным, именно так SQL Server сам отслеживает различные изменения, происходящие в базе данных между выпусками.

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

Более подробное обсуждение и некоторые примеры см. В Контроль версий и ваша база данных .

Answer 2

Вы действительно не ошибетесь с таким инструментом, как Visual Studio Database Edition. Это версия VS, которая управляет схемами базы данных и многим другим, включая развертывания (обновления) на целевом сервере (ах).

VSDE интегрируется с TFS, поэтому вся ваша схема базы данных находится под контролем версии TFS. Это становится «источником правды» для управления вашей схемой.

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

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

Answer 3

Вариант (1). Каждый разработчик может иметь собственную актуальную локальную копию БД. (Современное значение, воссозданное по последним сценариям, управляемым версией (база + инкрементные изменения + база данных + данные прогона). Для выполнения этой работы у вас должна быть возможность «одним щелчком» развернуть любую базу данных локально.

Answer 4

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

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

Answer 5

Вы смотрели на продукт под названием DB Ghost ? Я лично не использовал его, но он выглядит всеобъемлющим и может предложить альтернативу в качестве пункта 4 в вашем вопросе.