Что делится на разные задания, когда файлы, созданные в задании A, необходимы в задании B?(Пример построения приложения .NET с использованием MSBuild)

Question

Я думаю о лучшем способе структурирования рабочих мест в Хадсоне и о том, что разделить на рабочие места.В качестве примера я буду использовать приложение .NET, над которым я сейчас работаю, но я думаю, что многие идеи носят общий характер.

Это шаги, которые я хочу выполнить, не задумываясь.о делении вещей на рабочие места, но все еще думаю о том, что это за зависимости: (надеюсь, вы понимаете мою запись, <- означает, зависит от, а [X] = aaaaa означает, что aaaaa - это описание задачи [X].) </p>

• [C] = Извлечь проект, в данном случае используя Mercurial.
• [C] <- [S] = Запустить StyleCop для исходных файлов, чтобы убедиться, что они соответствуют нашему стандарту кодирования. </li>
• [C] <- [D] = Создать документацию из нашего проекта, используя DoxyGen или Sandcastle. </li>
• [C] <- [O] = Запустить плагин кода задач, чтобы получить хорошийпрезентация наших комментариев TODO и т. д. </li>
• [C] <- [B] = Постройте решение, используя MSBuild с целью Release.Результатом в этом случае будут файлы библиотеки, скомпилированные в файлы сборки DLL.Мы хотели бы заархивировать эти артефакты. </li>
• [B] <- [T] = Запустить тесты NUnit для файлов библиотеки. </li>
• [B] <- [F] = Использовать FxCop для полученияхороший статический анализ кода из файлов библиотеки. </li>
• [B] <- [W] = Используйте плагин предупреждений компилятора в журнале сборки, чтобы извлечь все предупреждения, выданные во время компиляции. </li>
• [D], [B] <- [R] = Выпуск, создать архив выпусков и загрузить его на сервер. </li>

Если я разделю все это на разные задания:

• Как получить извлеченный исходный код, полученный на шаге [C] на шаге [S], [D], [O], [B], для которого всем нужен исходный код?
• Как мне получить файл журнала MSBuild на шаге [W], который был сгенерирован на шаге [B]?
• Как мне получить результирующие артефакты DLL, сгенерированные на шаге [B] на шаге шаг [T], и[F] кому они нужны?

Моя главная проблема, если я разделю все шаги на разные проекты, это как получить эти вещи, эти файлы между разными• хорошо проектирует (я мог бы, конечно, обратиться к жесткому кодированию путей к файлам, но это кажется негибким, но я могу ошибаться).

С другой стороны, если я делю их на разные проекты, яполучить меньше сложности для каждого проекта, чем если бы я втиснул все эти шаги в один проект.Это может быть трудно поддерживать, если у меня есть столько вещей в одном проекте.И я также не смогу запускать разрозненные проекты параллельно, что, я думаю, ускорило бы весь процесс.

Answer 1

Вы перечислили довольно много задач для вашей работы.Обычно не имеет смысла иметь одну работу для каждой задачи.Это имеет больше смысла сгруппировать их.Например, по моему опыту, вам ничего не стоит иметь отдельную работу для оформления заказа.

Помните, что больше рабочих мест делает процесс сборки более хрупким и усложняет его обслуживание.Поэтому сначала установите свои цели / стратегию, а затем разделите процесс сборки на отдельные задания.

Философия, которой я придерживаюсь, - это частые проверки в хранилище, и каждая проверка не должна нарушать сборку.Это означает, что мне нужно убедиться, что разработчик получает быструю обратную связь после регистрации.Так что мне нужна одна работа C, B, T, W, а также S в этом порядке.Если вы предпочитаете, вы также можете запустить O и F с этой работой.Что этот заказ покупает вам.Вы получили быструю обратную связь по вашему наиболее важному пункту, скомпилировал ли кодВторым по важности вопросом является то, выполняют ли модульные тесты то, что они должны делать (модульные тесты).Затем вы проверяете по менее важным элементам (предупреждения компилятора и стандарты кодирования).После этого вы можете запустить свою статистику.Лично я запускаю O (ToDos) и F (анализ кода) в ночной сборке, которая запускает целый выпуск.Но вы также можете запускать весь выпуск при каждой регистрации.

Я бы разделил процесс сборки / выпуска на более мелкие этапы, если артефакты нужны быстрее.Для меня это обычно приемлемо, когда работа длится до 15 минут.Зачем?Потому что я получаю быструю обратную связь, если она ломается (это может быть менее 2 минут), так как работа останавливается здесь и не запускает другие (теперь бесполезные) задачи.Иногда я работаю параллельно.Для параллельного выполнения и при разделении задания я в основном использовал стандартные зависимости («задания для создания после ...») для запуска зависимых проектов, но в основном я использую плагин параметризованного триггера .Я все чаще использую плагин join для параллельного выполнения некоторых шагов, но могу продолжать, только если завершены обе части.

Для передачи файлов между двумя заданиями я использовал внешний репозиторий (простообщий каталог в Windows) и передает путь к файлам в качестве параметра для следующего задания.Я переключил поведение и теперь использую функцию архивного артефакта Хадсона и передаю URL выполнения задания следующей работе, чтобы загрузить их через HTTP.Это устраняет технические проблемы монтирования общих папок Windows в Unix (даже несмотря на то, что CIFS довольно неплохо работает).Кроме того, вы можете использовать плагин Clone Workspace SCM , который помогает, если вам нужно все рабочее пространство в других заданиях.

Answer 2

У меня другое понимание «работы». В моем случае я использую Hudson для создания нескольких проектов, для некоторых проектов у меня более одной работы, но не по тем же причинам, которые вы описали выше.

Я использую инструмент для создания проекта, такой как Ant или Maven, чтобы выполнить некоторые очень конкретные шаги моей сборки, например, ваши задачи [O] или [D]. Для более общих шагов я использую плагины hudson, которые обрабатывают эти процессы, такие как запуск модульных тестов, развертывание артефактов.

Я думаю, вы обнаружите, что многие из этих плагинов написаны на разных языках.

Несмотря на то, что Hudson - это удивительный мощный инструмент для непрерывной интеграции, я могу сказать, что сложные вещи сделаны Maven и его плагинами. Отчеты о покрытии кода, отчеты о найденных ошибках, создание сайта проекта, создание javadoc, инструментарий байт-кода - вот некоторые из задач, на которые я полагаюсь в Maven.

Итак, я использую разные задания, когда хочу, чтобы для каждой сборки была разная конечная цель, а не для создания цепочки элементов. Я хочу быть конечным набором артефактов.

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

Надеюсь, мой взгляд на использование Хадсона поможет.