Вы должны ограничить доступ ко всем базам данных и предоставить разработчикам доступ только к локальной базе данных (там, где они разрабатываются) и к серверу разработчиков, где они могут выполнять интеграцию. Лучше всего было бы, чтобы они имели доступ только к своей области разработки локально и выполняли задачи интеграции с помощью автоматической сборки. Вы можете использовать такие инструменты, как Redgates SQL для сравнения различий в базах данных. Я предлагаю, чтобы вы держали все свои изменения под контролем исходного кода (файлы .sql), чтобы у вас была рабочая история того, кто что сделал, когда и чтобы вы могли отменить изменения в БД при необходимости.
Мне также хотелось бы, чтобы разработчики запускали локальный скрипт сборки для повторного запуска своего локального окна разработки. Таким образом, они всегда могут откатиться назад. Что еще более важно, они могут создавать интеграционные тесты, которые проверяют состояние их приложения (хранилище и доступ к данным) и логику, хранимую в хранимой процедуре, автоматически. Запуск инициализации (сброс БД), тесты интеграции (создание пуха в БД), повторная инициализация для возврата БД в чистое состояние и т. Д.
Если вы являетесь пользователем в стиле SVN / nant (или аналогичным) с концепцией одной ветви в вашем хранилище, вы можете прочитать мои статьи на эту тему в DotNetSlackers: http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Build-automation-with-NAnt.aspx и http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Continuous-integration-with-CruiseControl-NET.aspx.
Если вы являетесь мастером сборки с несколькими филиалами, вам придется подождать, пока я напишу что-нибудь об этом виде автоматизации и управления конфигурацией.
UPDATE
@ Sazug: «Да, мы используем несколько сборок с несколькими ветвями, когда используем базовый сценарий + дополнительные сценарии :) Какие-нибудь базовые советы для такого рода автоматизации без полной статьи?» Чаще всего существуют две формы баз данных:
- вы управляете БД в новой среде непроизводственного типа (только для активных разработчиков)
- производственная среда, в которой у вас есть живые данные, накапливающиеся в процессе разработки
Первая настройка намного проще и может быть полностью автоматизирована от dev до prod и включать откат prod при необходимости. Для этого вам просто нужна папка скриптов, в которой каждая модификация вашей базы данных может храниться в файле .sql. Я не советую вам хранить файл tablename.sql, а затем делать его версию, как если бы вы были файлом .cs, где обновления этого артефакта sql фактически изменяются в одном и том же файле с течением времени. Учитывая, что объекты sql так сильно зависят друг от друга. Когда вы создаете базу данных с нуля, ваши скрипты могут столкнуться с серьезными изменениями. По этой причине я предлагаю вам сохранить отдельный и новый файл для каждой модификации с порядковым номером в начале имени файла. Например что-то вроде 000024-ModifiedAccountsTable.sql. Затем вы можете использовать пользовательское задание или что-то из NAntContrib или прямое выполнение одного из множества инструментов командной строки SQL.exe, чтобы запустить все ваши сценарии для пустой базы данных от 000001-fileName.sql до последнего файла. в папке updateScripts. Все эти сценарии затем регистрируются в вашем контроле версий. И поскольку вы всегда начинаете с чистого db, вы всегда можете откатиться, если кто-то новый sql нарушит сборку.
Во второй среде автоматизация - не всегда лучший путь, учитывая, что вы можете повлиять на производство. Если вы активно разрабатываете для / для производственной среды, то вам действительно нужна многоотраслевая / среда, чтобы вы могли протестировать свой способ автоматизации, прежде чем вы действительно столкнетесь с производственной средой. Вы можете использовать те же понятия, что указаны выше. Тем не менее, вы не можете начать с нуля на прод-дБ, и откат от него сложнее. По этой причине я предлагаю использовать RedGate SQL Compare в вашем процессе сборки. Сценарии .sql регистрируются для целей обновления, но перед запуском обновлений необходимо автоматизировать diff между вашими промежуточными db и prod db. Затем вы можете попытаться синхронизировать изменения и откатить продукт, если возникнут проблемы. Кроме того, некоторая форма резервного копирования должна быть предпринята до автоматического изменения SQL-изменений. Будьте осторожны, когда делаете что-либо без бдительного человеческого взгляда на производстве! Если вы выполняете настоящую непрерывную интеграцию во всех ваших средах разработки / квалификации / промежуточной обработки / производительности, а затем выполняете несколько ручных шагов при запуске в производство ... это действительно неплохо!