Мы используем CruiseControl.net, однако ваше первое требование может быть проблемой. Не могли бы вы объяснить, как вы делаете выбор в отношении того, из какого репозитория вы берете исходный код. CC.NET может работать с любым из них или может работать с обоими одновременно, если вы немного поумнели с настройками ccnet.config, но это больше зависит от того, как вы знаете, из какого из них брать.
В остальном это просто, я использую NAnt, чтобы делать настоящую работу, и до этого легко.
редактировать:
NAnt некоторое время не обновлялся, разработка остановилась с выходом MSBuild. Если вы выполните поиск по stackoverflow, вы найдете немало вопросов типа «должен ли я переключиться на MSBuild», лично у нас есть разумный объем знаний о NAnt, он делает то, что мы хотим, и есть некоторые вещи, которые мы делаем, которые появляются очень сложно в MSBuild, так что мы еще немного подождем.
В CruiseControl.NET есть задачи, которые могут вызывать MSBuild напрямую, мы по-прежнему вызываем DevEnv напрямую, поскольку мы создаем множество проектов развертывания, с чем у MSBuild возникают проблемы.
Наш сценарий NAnt проводит нас на всем пути от извлечения нужного источника из ClearCase до упакованного продукта, готового к отправке.
Однако NAnt - это всего лишь один из вариантов, если вас устраивает другой язык сценариев, такой как PowerShell, тогда нет причин, по которым его не следует использовать. CruiseControl.NET может вызывать любой исполняемый файл как задачу с помощью тегов и передавать большой объем информации с помощью переменных окружения. Эта страница: http://confluence.public.aughtworks.org/display/CCNET/Executable+Task подробно описывает, что передается.
С точки зрения использования тех же шагов, единственная разница между двумя настройками будет заключаться в блоке управления версиями в файле ccnet.config, наш скрипт NAnt вообще не меняется, когда мы меняем используемое представление, так как все относительно, и мы получаем иметь стандартный макет для наших представлений, что означает, что мы всегда знаем, где что находится.
Надеюсь, это поможет еще немного.
Алан.
person
Alan Mullett
schedule
13.03.2009
