Управление версиями SQL Server?

Question

Моя группа разработчиков использует Visual Source Safe для контроля версий; этот выбор изначально был сделан из-за его высокой стоимости и тесной интеграции с Visual Studio.

По мере роста нашего репозитория Source Safe действительно начала показывать свои ограничения, и мы рассматриваем возможность перехода к другому решению. Для обсуждения подойдут Team Foundation Server, Subversion, Git и Mercurial.

Мы в значительной степени являемся хранилищем данных, поэтому еще одним важным фактором для нас является возможность легко создавать версии проектов SQL Server 2005/2008. Это одно из преимуществ использования Source Safe, а также Team Foundation Server - интеграции с Microsoft SQL Server Management Studio.

Мне интересно, имел ли кто-нибудь опыт работы с версиями SQL Server с Subversion, Git или Mercurial и может ли предоставить некоторые надежные плюсы / минусы для каждой из этих систем, а также как вы их реализовали.

Answer 1

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

Мы используем Subversion и SQL 2005 вместе в следующем поместье:

• Мы используем только TortoiseSVN. Нет интеграции VS / SSMS.
• У нас есть принцип «автоматизировать все», поэтому мы никогда не полагаемся на инструменты GUI для выполнения работы.
• Мы храним все скрипты внутри SVN вместе с кодом. Код, схема и сценарии являются версиями вместе.
• Изменения схемы нумеруются в порядке приложения, то есть 000-create-table-users.sql. Мы записываем максимальное количество скриптов, развернутых в каждой среде. Каждый скрипт выполняет миграцию к следующей базе данных. При развертывании мы извлекаем исходный код и запускаем все сценарии с номера последней версии до наибольшего номера.
• Любые сценарии, не являющиеся схемами (sprocs / views), являются идемпотентными (могут выполняться любое количество раз с одинаковым результатом). Они применяются через плагин Nant, который мы написали. Они заменяются каждый раз, когда мы развертываем. Не забудьте обновить ваши взгляды!
• Мы по возможности избегаем любых сценариев, так как мы используем NHibernate, так что в любом случае проблем с версионностью сценариев меньше.

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

Однако мы НЕ используем его для модульного тестирования - мы полагаемся на генерацию схемы NHibernate, чтобы сделать это поверх базы данных SQLite.

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

Answer 2

Выпуск базы данных Visual Studio Team System 2008 (кодовое имя «DataDude») - это то, что вам нужно.

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

Ознакомьтесь с функциями в блоге Герт Драперс, начиная с этой записи .

Или, если вы предпочитаете подкаст, послушайте DotNetRocks с Крисом Селлсом в шоу 494 .

Я не знаю, ограничены ли вы TFS для контроля исходного кода при использовании DataDude, но это незаслуженно «недооцененный» член семейства Visual Studio.

Answer 3

Это может быть полезным инструментом для вас: http://www.liquibase.org/

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

Answer 4

Теперь мы добавили поддержку VSS в SQL Source Control, которая интегрируется с SSMS, чтобы обеспечить полностью интегрированный контроль исходного кода для разработки баз данных. Чтобы попробовать это, пожалуйста, посетите: http://www.red -gate.com / ОБЪЯВЛЕНИЯ / viewtopic.php? Т = 12265

Answer 5

Mercurial имеет интеграцию VS с VisualHG , если вы считаете, что DVCS - это путь. Мы используем это для проектов C ++ / C # в нашем магазине, и это работает достаточно хорошо. (OTOH, я никогда не использовал «полную» интеграцию, поэтому я рад работать с расширением проводника и / или командной строкой для подробной работы с VC.)

Answer 6

Git и Mercurial - единственные, что вы должны рассмотреть IMHO, остальные 2 слишком старомодны. Современные СКМ должны относиться к ветвям так же, как к git.

Сравнение мерзавца с меркурием см .: http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/, http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn.

У меня нет опыта интеграции SCMS с SSMS, но AFAIK нет ни в одной из упомянутых систем (кроме TFS). Я бы не назвал это недостатком, так как, например, GUI - довольно удобный инструмент, который вам покажется более приятным, чем такая интеграция. Это, по крайней мере, мой случай при переходе от SVN (с интеграцией VS с использованием Ankh) в Git (без интеграции вообще) ...

Answer 7

Потенциально существует множество альтернатив - SQL Server Management Studio (SSMS) поддерживает интеграцию с любым интерфейсом управления исходным кодом Microsoft MSSCCI . Таким образом, вы можете расширить поиск до систем контроля версий, в которых есть поставщик, совместимый с MSSCCI.

В SSMS проверьте Сервис -> Параметры -> Контроль источника, чтобы узнать, какие плагины поставщика установлены в вашей системе.

Например, интеграция Team Foundation Server с SQL Management Studio предоставлена ​​поставщиком TFS MSSCCI. Я думаю, что есть провайдер для CVS / Subversion («Aigenta Unified SCC») и т. Д.

Что касается списка плюсов / минусов, я думаю, что при наличии совместимого провайдера вы можете открыть вопрос для более широкой аудитории. Мой основной опыт работы с VSS, TFS и Subversion. Это действительно сводится к вашей команде и окружающей среде. Можете ли вы подробнее рассказать о своей среде?

например.

• Вас заинтересовало бы создание CI (непрерывная интеграция)?
• автоматизированные сборки / автоматическое управление версиями?
• поддержка нескольких сред?
• Управление конфигурацией?
• какой у вас размер команды? может быть много слияний / разветвлений и т. д.?
• у вас уже есть система отслеживания ошибок (вы получаете рабочие элементы / отслеживание ошибок как часть развертывания TFS)?

Answer 8

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