Принудительные правила для сборки и развертывания

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

Вопрос в том, как проверить, что, если производственное развертывание выполняется с использованием веб-проекта CC.NET, создается с использованием производственной сборки (не тестовой или другой)? Как принудительно выполнить определенные шаги при сборке и развертывании в производственной среде (например, сжать JS и CSS, скомпилировать с debug = "false" и т. Д.)? Теперь любой разработчик может вносить изменения в файл MSBuild (чтобы он / она мог забыть сжимать JS при производственной сборке и т. Д.).


build deployment msbuild rules cruisecontrol.net
person Sazug    schedule 05.11.2009    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я широко использовал CruiseControl с NAnt, но не MSBuild. Есть ли у вас разные файлы MSBuild для каждого типа сборки (например, local / test / prod)? Можете ли вы иметь один, который можно параметризовать, чтобы ваши интеграторы CCNet могли явно вызывать соответствующие параметры для целевой среды? Вот как у меня сконфигурирована моя непрерывная интеграция и сборки релиз-кандидата в CCNet. Один главный сценарий сборки NAnt и отдельный интегратор CC для каждой целевой среды с необходимыми параметрами сборки (будь то цели или значения свойств). Я полагаю, вы могли бы сделать что-то подобное с варами / целями MSBuild.

person Peter    schedule 05.11.2009
comment
Да, мы используем единый файл сборки и передаем ему параметры. Однако этот файл сборки может быть изменен любым разработчиком, и если, например, мы добавим новую функцию в наш сценарий развертывания, а разработчик забудет добавить ее в сценарий развертывания, это вызовет проблемы. Как проверить, что в файл сборки включена новая функция развертывания? - person Sazug; 05.11.2009