Хранимые процедуры в Source Control - автоматизировать процесс сборки / развертывания

Question

Моя компания предоставляет большое сервисно-ориентированное решение .NET. Уровень служб взаимодействует с серверной частью T-SQL, состоящей из сотен таблиц и хранимых процедур. Наш код C # находится в системе контроля версий (SVN), а наши хранимые процедуры и схемы - нет.

После большого лоббирования целесообразного высшего руководства мне разрешили пересмотреть наш (несуществующий) процесс сборки / развертывания для достижения следующих целей:

1. Поместить схему и хранимые процедуры в систему контроля версий.
2. Автоматизация процесса сборки / развертывания.

Я бы хотел действовать согласно стратегии принятого ответа в этом посте , но у меня есть дополнительные вопросы:

1. Я хотел бы использовать Hudson в качестве сервера сборки. Это разумный выбор для решения C # / SQL? Какие лучшие альтернативы мне следует изучить?

2. Предполагая, что все триггеры, хранимые процедуры, схемы и т. Д. Находятся под контролем исходного кода, и что они записаны в сценарии для отдельных файлов, как мне создать сценарий сборки, который будет учитывать зависимости / ссылки между этими предметами? (SQL Server делает это автоматически, но генерирует один гигантский скрипт)

3. Как выглядит процесс выполнения обновления на клиенте? т.е. я должен сохранить существующие данные таблицы. Как откатить изменения схемы?

4. Я единственный программист. Некоторым другим псевдотехническим сотрудникам нравится вносить изменения непосредственно в SQL Management Studio. Реально ли ожидать, что другие будут придерживаться этого решения - как я могу обеспечить это?

Заранее благодарю за помощь.

Edit:

К сожалению, мы не сможем использовать TFS. Тем не менее, у нас есть Visual Studio 2008/2010 с доступными компонентами проекта базы данных, так что, похоже, мне придется взломать решение на основе сценариев. Любые предложения / обновления приветствуются.

Answer 1

Каноническим примером в стеке Microsoft для развертывания T-SQL является процесс развертывания проекта базы данных Visual Studio. В этом процессе схема базы данных, процедуры, назначение прав и почти все остальное хранятся в виде фрагментов проекта VSDB, что означает, что они хранятся в виде файлов определений SQL и проверяются под контролем исходного кода (это нормально для SVN). Процесс 'build' предоставляет файл .dbschema, который представляет собой синтез всего проекта VSDB (это прославленный файл XML). Файл .dbschema затем отправляется на сервер развертывания (сервер разработки, сервер проверки качества, даже сервер производства) и «развертывается». Развертывание осуществляется с помощью инструмента vsdbcmd , который запустит сложную разность между сервером развертывания и файлом .dbschema и «выровняет» сервер по содержимому файла .dbschema, используя операторы CREATE / ALTER / DROP в зависимости от обстоятельств, исходя из того, что существует в целевой базе данных / сервере.

Непрерывно интегрированный процесс запускает ночную сборку, удаляет .dbschema вместе с другими результатами на тестовом SQL-сервере, развертывает .dbschema, затем запускает проверочные тесты сборки, и если все хорошее в конце концов отбросит полную сборку и QA подтвержденный результат, ежедневное «падение». Возможна полная интеграция на всех этапах развертывания в производство, но ее обычно избегают из-за риска непредвиденных простоев на центральном, производственном сервере. Однако полная интеграция и развертывание в производство обычно является нормой для многосерверных сред, где «производство» означает сотни / тысячи развернутых серверов.

Теперь вы говорите, что хотите выполнить развертывание с использованием Hudson, и это хорошо, за исключением того, что вам нужно воссоздать все, что я описал в приведенных выше шагах, как этапы сборки Ants, и вы потратите следующие 10 лет на переосмысление проекта VS DB такие понятия, как файл .dbschema и такие инструменты, как vsdbcmd. Я не тот, кто может призвать инвестировать в покупку лицензии на сервер сборки на базе VSDB и TFS, но я говорю, что не знаю комплексного решения, доступного в OSS. Я считаю, что в VS 2010 проекты баз данных выпускаются в стандартной версии. С VS 2008 вам понадобится лицензия высокого класса.

Что касается пользователей, выполняющих изменения при стрельбе из SSMS: вы можете предотвратить их, используя DDL триггеры , вы можете отслеживать их, используя Уведомления о событиях , или вы можете полностью проверять их, используя C2-совместимый аудит .