Управление изменениями базы данных и процесс сборки с использованием TFS [закрыто]

Question

Кто-нибудь использует Team Foundation Server для управления своими базами данных?В настоящее время мы используем Subversion.Команда жалуется, что в TFS сложно создать процесс сборки, и уклоняется от этого.

Есть ли хорошие советы, статьи, опыт?

Answer 1

Управление изменениями в БД не имеет особого отношения к выбору системы контроля версий, если она у вас вообще есть.Конечно, если вы используете инструменты управления изменениями от MS, вы можете быть совершенно уверены, что они достаточно хорошо протестированы на TFS и остальной части стека разработчиков MS.Это верно независимо от того, используете ли вы DBPro или гораздо более старые/более дрянные формы интеграции, которые можно увидеть в классическом «проекте базы данных» VS или в урезанных привязках проекта/решения в SQL Management Studio.Но нет причин, по которым вы не могли бы использовать DBPro с Subversion или Red Gate с TFS, если уж на то пошло.

То же самое касается генерации сборки.CC.NET против Team Build, NAnt против MSBuild и т. д. Официальные инструменты MS, как правило, примерно на одном уровне с конкурентами.Вы не описали подробно процесс развертывания БД, но я не могу себе представить, что писать сценарии в MSBuild будет значительно сложнее, чем то, что вы используете сейчас, если вообще сможете.Также нетрудно выбрать разные наборы инструментов в разных точках стека:вы можете иметь сборки на основе MSBuild на диске CC.NET, которые используют развертывание из командной строки Red Gate, или любую другую комбинацию.Я думаю, что тесная интеграция, обеспечиваемая приверженностью миру MS, намного перевешивает особенности любого отдельного инструмента, но выбор есть.

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

Помимо этого, самая важная инвестиция — это добиться того, чтобы ничего не делалось напрямую с БД (не больше, чем вы копались в %programfiles%).Если его нет в исходном репозитории, значит, он не существует.

Я не думаю, что то, как вы туда доберетесь, так уж важно.Вы можете написать все свои CREATE и ALTER в Блокноте, зарегистрировать их из командной строки и сделать так, чтобы ваш «процесс сборки» представлял собой двухстрочный сценарий оболочки, который объединяет их в известный файл, который знает сценарий развертывания. .Или вы можете использовать модный инструмент, такой как DBPro, чтобы повысить свою производительность с помощью intellisense/модульного тестирования/офлайн-моделирования и т. д.Есть веские причины двигаться в последнем направлении (особенно если вы верите в то, что декларативное программирование в целом есть к чему стремиться), но я действительно считаю, что первый шаг — самый большой.

Answer 2

Мы используем Visual Studio 2008 Team Suite вместе с TFS.Мне удалось относительно легко импортировать наши базы данных в TFS.Однако я обнаружил, что большая часть команды (включая администраторов баз данных) забывает обновить TFS при изменении объекта в SQL.

Любой процесс сборки будет полагаться на DB Pro для создания сценариев различия между вашей средой разработки и целевой средой.Я обнаружил, что это проблематично, поскольку наша среда разработки не полностью соответствует нашей производственной среде.Разрешения, конечно, разные, и у нас есть ряд других случаев, когда изменения были применены в dev/QA, но никогда не переносились в рабочую версию (но также никогда не были отменены).Попытка изолировать ваши изменения от множества других изменений в DB Pro является сложной задачей, поскольку пользовательский интерфейс заставляет вас исключать объекты из окончательного сценария (поэтому, если вы измените 2 объекта, а 1000 других будут отличаться, вам придется снять флажки с остальных 1000 объектов).Кроме того, настройка сравнения схем часто выполняется в меню «Инструменты->Параметры», тогда как другие инструменты, такие как Red Gate, позволяют вам настроить сравнение на том же экране, на котором вы его запускаете.

Я думаю, что у этого инструмента есть потенциал, но нам, безусловно, необходимо адаптировать существующие процедуры и системы для работы с TFS.Кроме того, наличие версий объектов базы данных имеет неоценимое значение, даже если они не обновлены на 100 %.

Answer 3

Мы используем TFS с редакцией базы данных.

Скрипт создания базы данных имеет пост-скрипты для загрузки данных разработки в БД.

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

В среде модульного тестирования логины, базы данных (OLTP и OLAP), репликация, пакеты ETL, задания SQL и т. д.все развернуты в своих местах и ​​все засеяно.

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

Answer 4

В этом вопросе о переполнении стека гораздо больше мнений по этому поводу:Каковы реальные преимущества Visual Studio Team System Database Edition (GDR)?(Я не знаю почему, но вместо этого мои поиски привели меня к этому вопросу, и мне было очень трудно найти мнения по этому поводу.Надеюсь, эта ссылка поможет другим, выполняющим тот же поиск.)