Что должно быть в скрипте MSBuild, кроме компиляции?

Question

В настоящее время я пытаюсь настроить CruiseControl.net, и поэтому мне интересно, как разделить мои задачи.

Как правило, я хочу запускать модульные тесты (xUnit.net), генерацию файлов справки (Sandcastle) и FxCop.

Теперь мне просто интересно, должен ли я указать новую цель в конфигурации msbuild ("Документация") и использовать ее для запуска SandCastle, или это относится к отдельному скрипту?Кроме того, msbuild предназначен для создания чего-либо, поэтому я предполагаю, что ncover, xunit и FxCop не должны быть его частью, или они должны?

Какова предполагаемая область применения msbuild?

Answer 1

Поместите почти все в скрипты MSBuild, чтобы вы и другие разработчики могли выполнять те же действия локально через командную строку.В противном случае, когда что-то пойдет не так со сборкой, вам придется отлаживать ее на сервере CC.Не самый приятный опыт отладки.Кроме того, вы хотите запустить сборку локально до того, как обязуюсь убедиться, что это работает.

Несколько вещей, которые я бы НЕ стал вкладывать в скрипты MSBuild, это:

• Обновление SVN, поскольку CC все равно должен это делать, а вы обычно не хотите обновлять при выполнении локальной сборки.(Ну, я делай Тип svn up && msbuild довольно часто, но это настолько коротко, что мне не нужно вставлять это в сценарий.)
• Создание и публикация отчетов о сборке;опять же, это домен CC, и он не полезен локально

Что касается структурирования ваших файлов MSBuild, вам понадобится "главный" скрипт сборки, который вы можете использовать для сборки всего или просто некоторые цели, например

• MSBuild /t:Build просто создавать код постепенно
• MSBuild /t:Rebuild для чистой перестройки
• MSBuild /t:UnitTest просто запускать модульные тесты
• MSBuild для наиболее частого выбора, скажем, эквивалентного t:Build;UnitTest
• MSBuild /t:All чтобы создать код, документацию и выполнить настройку без ошибок, запустите все тесты и упакуйте результаты

Вы также можете добавить цели "быстрого доступа" для популярных вариантов.

Наличие одного основного файла сборки не означает, что все определено в этом одном файле;вы можете включить другие файлы msbuild и / или рекурсивно вызвать msbuild для организации вашей сборки.Например:

• Файл master .proj должен быть относительно простым;в основном, он должен определять специфичные для проекта элементы, такие как список решений для сборки и переопределения для конкретного проекта
• Пусть главный файл включает в себя один файл .targets, который содержит целевые объекты и свойства по умолчанию;стремитесь сохранить этот проект нейтральным и пригодным для повторного использования.
• Если файл .targets становится слишком большим, разделите его на отдельные файлы, напримеродин для кода, один для справки и документации, один для настройки и упаковки.Позвольте вашему основному файлу .targets включать эти вложенные файлы, чтобы ваш файл .proj по-прежнему должен содержать только один файл
• Аналогично, вы можете разделить файл master .proj, если это необходимо, напримерпо подсистеме.

Answer 2

У меня есть сценарий сборки для отдельных проектов, и я просто объединяю их в цепочке второй файл сборки при создании пакета ... например, мой файл сборки protobuf-net обрабатывает управление версиями (SVN) , компиляция (MSBuild + NAnt для моно), тестирование (NUnit), упаковка (zip) и т. д. Это ваш процесс сборки; делайте то, что вам нужно ;-p Если бы я мог, например, сделать развертывание и документацию, если я хотел.

Это также зависит от того, как вы работаете; если вы используете CruiseControl, он может решить большую часть этого для вас. Для себя мне нравится командная строка " build " шаг.