Какой предпочтительный способ настроить непрерывную интеграционную сборку для большого проекта с TeamCity?

Question

Некоторое время моя компания использует Maven и TeamCity для создания Java-приложений.В настоящее время мы инвестируем значительные средства в непрерывную интеграцию и, в конечном итоге, в непрерывную поставку.

Среди множества небольших приложений (приложений) мы работаем с одним большим монолитным приложением с прим.1 миллион LOC.Это приложение на довольно большом сборочном агенте занимает 5 минут на компиляцию (включая 2 минуты на запуск).Её 12k юнит-тестов продолжаются ещё 5 минут.Развертывание результатов сборки в Nexus занимает не менее 10 минут.

Чтобы обеспечить быструю обратную связь с разработчиками, мы стараемся разделить объем работы, выполняемой в различных задачах сборки.В настоящее время мы используем следующую настройку:

• Шаг 1. Скомпилируйте все (5 минут) и, если это не получится, прервите цепочку.Запустите сборку изменений SVN.
• Шаг 2. Компиляция, проверка и развертывание.(От 20 до 40 минут, в основном в зависимости от производительности Nexus и / или сети). Определите зависимость моментального снимка от Step.Инициируйте сборку при изменениях SVN, но только если изменились зависимости моментального снимка.

Хорошая новость: шаг 2 создается только при успешной сборке с изменениями шага 1.

У этого подхода есть существенный недостаток: Шаг 2 делает все, что Шаг 1 уже сделал.И если я собираюсь представить развертывание в тестовой системе в качестве шага 3 и тесты Selenium на уровне браузера в качестве шага 4, многие вещи будут выполняться дважды или трижды.

Альтернативы, которые мы попробовали:

• Настройте Шаг 2 для запуска на том же агенте сборки, что и Шаг 1, но svn up будет выполнен в любом случае, поэтому здесь нет никаких преимуществ.Единственное, что было бы немного лучше: кэширование Maven.
• TeamCity Build Steps.Насколько я узнал, они вряд ли дают какое-либо преимущество для разделения задач сборки с недостатком отсутствия промежуточных результатов сборки.

Кто-нибудь знает лучший подход, как настроить это лучше?

Большое спасибо, Стефан

Answer 1

Теперь у нас есть неделя с зависимостями моментальных снимков, и я полюбил их, помимо их неэффективности.

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

Так что спасибо тем, кто проявил интерес к этому вопросу.Я закрою это сейчас.

Answer 2

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

Развертывание на Nexus является узким местом, поскольку оно занимает от 10 до 20 минут (в зависимости от сети и Nexus), в то время как остальные этапы также составляют в целом 10 минут. Я заметил, что мы развертываем в Nexus больше, чем необходимо для непрерывной интеграции: не только артефакты Maven, но и результаты, такие как RPM или войны. Вполне возможно, что половина времени развертывания - только из-за этого.

Мы могли бы настроить третий шаг «Шаг 3: Создание результатов». Это может быть основано на собственном POM для этой проблемы, чтобы избежать того, что все скомпилировано и протестировано. Это POM будет зависеть от снимка от артефактов Maven, созданных на 2-м шаге.

Но я не уверен, что это лучший способ сделать такие вещи в Maven или TeamCity. Тем не менее, я надеюсь на другие решения или мысли.