В нашем текущем dev. рабочего процесса есть основная база данных --> DbMain. Есть процесс, который берет последнюю версию проекта и автоматически развертывает ее там, после чего запускает модульные тесты. Так как хотелось бы, чтобы в исходном контроле всегда была рабочая версия проекта, каждый разработчик должен быть уверен, что он проверяет рабочий код и все тесты будут пройдены.
Для этого мы решили создать отдельные базы данных для каждого разработчика со следующим соглашением об именах --> DbMain_XX (где XX< /strong> — инициалы разработчиков). Таким образом, каждый разработчик перед регистрацией должен опубликовать все изменения в этой базе данных вручную и запустить модульные тесты. Для этой цели полезно настроить конфигурацию публикации, которая является копией основной конфигурации публикации с единственной разницей в именах баз данных.
Это означало бы, что у нас будет много разных профилей публикации в решении, что довольно беспорядочно.
Если мы не добавим эти профили в систему управления версиями, то файл .sqlproj по-прежнему будет иметь ссылку на эти файлы, поэтому проект будет иметь ссылку на несуществующие файлы.
Итак, собственно вопрос. Могу ли я иметь единый профиль публикации для всех разработчиков, в котором имя базы данных будет изменено с помощью переменных? Например, DbName_$(dev_initials)? Или можно сделать так, чтобы у каждого разработчика были свои конфиги публикации только локально и это не ломало бы проект?
ОБНОВИТЬ:
Согласно комментариям Питера Шотта:
Я могу создать локальный профиль публикации, но если я не добавлю его в систему управления версиями, то все равно будет запись в файле sqlproj, но сам файл будет недоступен.
Запуск тестов локально имеет как минимум 2 недостатка. Во-первых, предполагается, что каждый должен установить SQL Server локально. В основном мы работаем через виртуальные машины, и дисковое пространство там весьма ограничено. Другое дело, что разработчики точно забудут или не будут каждый раз запускать тесты вручную. Иногда они вносят изменения в репозиторий, не создавая его и/или не запуская тесты. Мы хотели бы избежать подобных ситуаций и как можно быстрее «отловить» неудачную сборку.
Другой подход, о котором упоминалось, заключается в том, чтобы иметь 1 общую базу данных сборки. И в моем случае у нас есть один (DbMain). Все разработчики могут использовать его для своих нужд, но мы обязательно поймаем ситуацию, когда 2 разработчика будут публиковать одновременно, и это может внести много путаницы, выяснив, что на самом деле пошло не так.
