Ой, заморачивайся. Visual Studio 2003 и Cruise Control.NET. Просто и элегантно. Базовый сценарий NAnt для построения решения, и все готово. Запустите NUnit, выходные данные перейдут в формат, понятный CC и вашему дяде Боба. Позвольте мне оценить это количественно. На нашем круизном сервере есть клиент Subversion (командная строка) и .NET 1.1 SDK. Visual Studio не установлена, потому что, да, это сервер, и круизу просто нужно что-то для сборки системы.
Войдите в Visual Studio 2005. Я совсем недавно настроил CI для наших проектов 2005 года, но во многих отношениях это просто уродливо. Сначала была попытка собрать систему с помощью MSBuild. Это было нормально, потому что вы можете просто ввести это:
msbuild /t:rebuild имя_решения.sln
(или любую другую цель, которую вы хотите, например, Debug или Release).
Как я уже сказал, если это все, то это не проблема, но очень быстро становится очень некрасиво.
Во-первых, это проекты модульного тестирования VSTS. Вся команда оснащена Visual Studio Team Suite. Дорогостоящее предложение, но оно было сделано давным-давно кем-то мудрее меня. Хотя нет проблем. На самом деле мы не особо используем Test Manager, автоматизированных веб-тестов нет, поэтому мы просто пишем модульные тесты (и запускаем их с помощью превосходного TestDriven.NET Джейми Кансдейла). Однако когда MSBuild получает решение, содержащее проект модульного тестирования VS, ему требуется некоторый дополнительный набор сборок (сборки, скрытые в GAC_MSIL и других местах). Фрагмент файла ccnet.config для запуска MSBuild был довольно простым:
<исполняемый файл>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe
При помощи грубой силы (запустить MSBuild, выяснить, какая сборка ему нужна, найти ее, намылить, промыть, повторить) мне удалось скомпилировать решение 2005 года (с проектами модульного тестирования). Однако на самом деле проведение тестов — это совсем другая история. Здесь снова царила грубая сила, поскольку я потратил час или два на запуск MSTest.exe, пытаясь уговорить запустить пару сотен модульных тестов. Запись cc.config для получения некоторых модульных тестов выглядит примерно так:
<исполняемый файл>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe
Помните, я сказал, что на этом сервере не установлена Visual Studio. Для решений VS2005 я только что установил .NET SDK 2.0, и этого было достаточно. Хотя MSTest.exe не включен, я взял файл (и это сумасшедший набор дополнительных DLL, разбросанных по всему жесткому диску) из другой системы и вставил его туда, где был EXE, чтобы он был счастлив.
Никаких проблем с запуском MSTest для проекта модульного тестирования. Все началось с запуска теста, но затем возникла сумасшедшая ошибка COM (CLSID не зарегистрирован), и мне этого было достаточно. Я ни в коем случае не буду искать все эти дурацкие настройки реестра COM для Visual Studio 2005. И что это, черт возьми, было? КОМ? Я думал, мы избавились от этого около 3 компиляторов назад?
Поэтому я решил установить на сервер полную версию Team Suite. Хорошо, я укушу. Я имею в виду, что мне не нужно все, так что все будет в порядке (я продолжаю говорить себе, наблюдая, как заполняется миллион записей в реестре). Несколько часов спустя я снова смотрю на командную строку и ввожу команду MSTest.exe. И появляется диалоговое окно. Да, модальное диалоговое окно, которое сообщает мне, что что-то не так (я не помню подробностей, но оно было не очень информативным).
Visual Studio была установлена нормально, и я смог скомпилировать, запустить и построить решение, которое пытался создать, но тестирование из командной строки с помощью MSTest.exe оказалось невозможным. Как бы я ни старался, сколько бы я ни очистился или сколькими девственницами я пожертвовал, это все равно не пройдет. И есть еще одна проблема. С 2003 годом и нашими тестами NUnit мы получили неплохую статистику. Тайминги, информативные сообщения и все такое хорошее. С помощью MSTest мы ничего не получаем (кроме количества выполненных тестов x и, возможно, сбоя, но я не смог зайти так далеко, чтобы увидеть, даст ли это подробную информацию о сбое). Вдобавок ко всему, регистратор MSBuild кусает и выдает около 10 000 строк бессмыслицы, которая не очень полезна. Да, я мог бы потратить свое время на написание нового xslt, чтобы сделать его красивым, обрезать строки «Все было хорошо», которые заполняют журнал задач MSBuild, но я думаю, что это не принесет никакой пользы при моих расценках.
Вот пример электронного письма, которое я получил после сборки, которое дает вам представление о том, насколько бесполезна комбинация CC.NET/MSBuild/MSTest:
BUILD SUCCESSFUL
Проект: PROJECTNAME
Дата сборки: 08.12.2006 8:08:30
Продолжительность: 00:00:55
Запрос на интеграцию: интервалTrigger инициировал сборку (ForceBuild)
Ошибки (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): ошибка MSB4041: пространством имен XML проекта по умолчанию должно быть пространство имен MSBuild XML. Если проект создан в формате MSBuild 2003, добавьте xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " в <Project> элемент. Если проект создан в старом формате 1.0 или 1.2, преобразуйте его в формат MSBuild 2003.
Предупреждения (1)
SourceReportsServerReportsServerReports.rptproj (,): предупреждение MSB4122: Ошибка сканирования зависимостей проекта для проекта "SourceReportsServerReportsServerReports.rptproj". Пространством имен XML проекта по умолчанию должно быть пространство имен MSBuild XML. Если проект создан в формате MSBuild 2003, добавьте xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " в <Project> элемент. Если проект создан в старом формате 1.0 или 1.2, преобразуйте его в формат MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Тестов выполнено: 0, Сбоев: 0, Не выполнено: 0, Время: 0 секунд
Тесты не выполняются
В этом проекте нет тестов
Изменения с момента последней сборки (0)
Это некрасиво. Действительно некрасиво. MSBuild выдает массу сумасшедших результатов. Написание нового файла MSBuild — непростая задача, и даже для такого человека, как я, который достаточно хорошо знает NAnt, я все еще пытаюсь понять, как MSBuild что-то делает. Мне пришлось создать специальную конфигурацию внутри Visual Studio, чтобы исключить наш проект отчета, поскольку MSBuild не может их построить (следовательно, указанная выше целевая AutomatedBuild не является той конфигурацией, которую используют наши разработчики, и мне это не нравится, потому что это одна точка CI-сервера, последовательные сборки для всех).
Судя по приведенным выше выводам, Круз сказал, что сборка прошла нормально, но из средства регистрации MSBuild (наш проект отчета) появилось сообщение об ошибке. Это проект 2005 года, поэтому информация не имеет смысла (я полагаю, что это зарегистрированная ошибка, но кто знает, когда ее могут исправить). И я действительно не могу интегрировать результаты MSTest в электронное письмо, потому что их нет. В этом проекте около сотни тестов, но регистратор ничего не выдает.
Кроме того, есть некоторые типы проектов, с которыми MSBuild не может справиться, и, опять же, требуется ученый-ракетчик, чтобы создать файл MSBuild (даже с использованием чего-то классного, например MSBuild Sidekick), который может вызывать другую задачу MSBuild и исключать определенные проекты. Это, конечно, не так просто, как в 2003 году, когда вы только что создали список исключений (мы исключили наше клиентское приложение, поскольку не было дополнительной лицензии для управления сеткой, и появлялось модальное диалоговое окно, когда пробная версия даже просматривалась пользователем). компилятор).
Ладно, это по большей части напыщенная речь, но здесь есть некоторая мудрость. Непрерывная интеграция не должна быть такой сложной. CruiseControl.NET — отличный инструмент, очень гибкий благодаря новым инструментам и интеграции результатов этих инструментов. Однако, когда этим инструментам требуется миллион настроек реестра и даже больше DLL (размещенных в очень определенных местах, поверьте мне, вы не можете просто бросить их в GAC и положить конец) и сбрасывать кучу XML, которые не может получить ни один простой смертный (ну возможно DonXml смог бы) перевести, это просто неправильно. А что касается встроенной Team Build, которую вы могли бы нам использовать, она столь же бесполезна, как и а) вы не можете запланировать сборку для запуска проверок кода и б) опять же, для этого требуется, чтобы на сервере был установлен полный клиент Team Suite. . В худшем случае, когда я впервые начал настраивать серверы CC.NET, это заняло 4 часа. Теперь я могу сделать это за час (включая тестирование сборки первого проекта). Я уже потратил хороший день, пытаясь что-нибудь скомпилировать. Сейчас он компилируется, но результат — дерьмо, тесты не выполняются, и для меня этого недостаточно. Вы можете запустить MSBuild и (возможно) MSTest с помощью CruiseControl.NET. Это не невозможно. Если вы установите полную версию клиента и ваши проекты «в порядке», он будет работать, но результат не такой уж горячий, и вы будете наблюдать, как процессор вашего сервера падает при компиляции.
Мой совет: избегайте попыток объединить MSBuild, MSTest и CruiseControl и придерживайтесь NAnt и NUnit (при необходимости используйте MSBuild при создании решений 2005 года).
Излишне говорить, что я сейчас рассматриваю один вариант. Сброс установки VS2005 на сервер, изменение всех наших модульных тестов обратно на NUnit и использование NAnt для всех действий (и просто вызов MSBuild в качестве задачи выполнения для проектов VS2005). Мне все еще нужно запускать проекты 2003 года, чтобы к тому времени, как я закончу, наш CI-сервер будет выглядеть как монстр Франкенштейна, создавать проекты VS2003 и VS2005, запускать NUnit, MSBuild, NAnt, Simian, FxCop и все остальное, что у нас есть в нашем смешивание. Даже учитывая, что при использовании NAnt выходные данные будут проще (и хорошо интегрируются с CC.NET), выходные данные теста будут полезными и информативными, и мне не нужно устанавливать программное обеспечение стоимостью 15 000 долларов на сервер, который имеет явную возможность чтобы когда-нибудь открыть модальное диалоговое окно, когда не удастся найти какой-либо ключ реестра.
Гррр. Ага.