Как лучше всего настроить сервер тестирования интеграции?

Вы определенно хотите разбить задачи. Вот хороший пример конфигурации CruiseControl.NET, которая имеет различные цели (задачи) для каждого шага. Он также использует файл common.build,который может быть разделен между проектами с небольшой настройкой.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn / ствол

Я использую TeamCity с nant скриптом сборки. TeamCity упрощает настройку серверной части CI, а nant build script упрощает выполнение ряда задач, связанных с генерацией отчетов.

Вот статья, которую я написал об использовании CI с CruiseControl.NET, в ней есть скрипт сборки nant в комментариях, который можно повторно использовать в разных проектах:

Непрерывная интеграция с CruiseControl

Подход, который я предпочитаю, заключается в следующей настройке (фактически предполагая, что вы находитесь в проекте .NET):

• CruiseControl.NET.
• NANT задачи для каждого отдельного шага. Nant.Contrib для альтернативных шаблонов CC.
• NUnit для запуска модульных тестов.
• NCover для выполнения покрытия кода.
• FXCop для отчетов статического анализа.
• Subversion для системы управления версиями.
• CCTray или аналогично на всех коробках разработки, чтобы получить уведомление о сборках и сбоях и т.д.

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

То, что я делаю в этих случаях, - это создаю три сборки (или, может быть, два):

• Построение CI инициируется проверкой и выполняет чистый SVN Get, Build и запускает легкие тесты. В идеале вы можете сохранить это до нескольких минут или меньше.
• Более полная сборка, которая может быть ежечасной (если изменения), которая делает то же самое, что и CI, но выполняет более полные и трудоемкие тесты.
• Ночная сборка, которая делает все, а также выполняет покрытие кода и статический анализ сборок и выполняет любые шаги deployment для создания ежедневных пакетов MSI и т. д.

Самое главное в любой системе CI - это то, что она должна быть органичной и постоянно корректироваться. Есть несколько отличных расширений для CruiseControl.NET, которые регистрируют тайминги построения диаграмм и т. д. Для шагов и позволяют вам делать исторический анализ и поэтому позволяют вам постоянно настраивать сборки, чтобы они были быстрыми. Это то, что менеджеры находят трудным принять, что коробка сборки, вероятно, будет держать вас занятым в течение пятой части вашего рабочего времени только для того, чтобы остановить его скрежетание.

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

Например, на моей текущей позиции мы строим подблоки для каждой из наших платформ (Mac, Linux, Windows) на их соответствующих платформах. Затем у нас есть один шаг (с несколькими подшагами), который компилирует их в окончательную версию, которая будет в конечном итоге в окончательных дистрибутивах.

Если что-то пойдет не так на любом из этих этапов, это довольно легко диагностировать.

Мой совет-напишите шаги на доске в максимально расплывчатых выражениях, а затем основывайте свои шаги на этом. В моем случае это было бы так:

1. Сборка Плагинов Pieces
   1. Компиляция для Mac
   2. Компиляция для PC
   3. Компиляция для Linux
2. Сделать окончательные Плагины
3. Запуск тестов плагинов
4. Построение промежуточных IDE (у нас в здании начальной загрузки )
5. Окончательная сборка IDE
6. Выполнить тесты IDE

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

В любом случае, вы должны быть в состоянии создать одну большую работу из меньших частей.

Добрый день,

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

</thebloodyobvious> (-:

овации, Грабить

Разбейте ваши задачи на дискретные goal/operations,, а затем используйте скрипт более высокого уровня, чтобы связать их все вместе соответствующим образом.

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

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

Для среды моей команды мы используем NAnt, так как она обеспечивает общую среду сценариев между машинами разработки (где мы пишем/отлаживаем сценарии) и сервером CI (так как мы просто выполняем одни и те же сценарии в чистой среде). Мы используем Jenkins для управления нашими сборками, но в своей основе каждый проект просто вызывает один и тот же сценарий NAnt, а затем мы манипулируем результатами (т. е. архивируем выходные данные сборки, помечаем неудачные тесты и т. д.).