Как и Glennular, мы используем их для контроля версий нашей схемы и s'procs.
Хотя у нас достаточно продвинутая структура контроля версий (CI, автоматическое развертывание в dev, развертывание в один клик для stage и prod); мы не включаем ни один из проектов БД в эту структуру. Мы просто пока этому не доверяем.
ОБНОВЛЕНИЕ: (для выхода в космос)
У нас есть отдельные проекты TFS для функциональных областей компании (Sales, Marketing и т. Д.). В каждом проекте TFS у нас есть папка Main и Production. У нас также есть один проект TFS, который содержит проекты базы данных, и еще один, который содержит общие сборки / проекты Visual Studio.
После выпуска мы разветвляемся от Main к Production. У нас нет промежуточной ветви, поскольку мы движемся слишком быстро, чтобы справиться с этим. Правильно или нет, наша производительность частично измеряется количеством выпусков уровня производства, которые мы делаем за неделю; исправления ошибок, новые функции и т. д.
CI настраивается в ветви Main таким образом, что при каждой регистрации сервер Build развертывается в наших средах DEV. Затем запускаются модульные и веб-тесты, и качество сборки автоматически устанавливается на «Разработка», если оно завершается успешно. Когда кто-то изменяет Качество сборки на «В промежуточном состоянии», это приводит к тому, что для всех предыдущих сборок «В промежуточном режиме» устанавливается значение «Отклонено», и при этом эти сборки передаются на наши промежуточные серверы при обновлении файлов конфигурации, чтобы они указывали на правильные серверы. (Для этого я использовал сценарии TFS Deployer и PowerShell).
QA проводит тестирование наших промежуточных серверов. Как только они счастливы, производственная команда меняет Качество сборки на «Производство». Это приводит к тому, что сборка отправляется в рабочую область, которая затем вручную копируется в правильное местоположение. После завершения, производство уведомляет разработчиков, которые затем разветвляют эту версию в папку Production. QA также уведомляется о том, кто затем проводит ряд производственных тестов, чтобы убедиться, что все действительно работает должным образом.
У нас есть отчеты, настроенные для того, чтобы показать нам, какие изменения существуют между производственными выпусками, чтобы мы знали о каждой проверке, которая развертывается. Это предотвращает появление неизвестных, таких как изменение базы данных и т. Д., Или какого-либо другого потенциально опасного кода.
Кроме того, наши БА отслеживают рабочие элементы через Team System Web Access и знают, когда эти элементы находятся в производстве.
Хотя наши администраторы баз данных используют Database Edition (GDR), они не были впечатлены уровнем контроля для автоматического развертывания. Я надеюсь, что Rosario привнесет лучший контроль развертывания в линейку продуктов; но до тех пор у нас есть TFS Deployer и powershell.