Как организовать полный строительный трубопровод с помощью Gulp, Maven и Jenkins, вплоть до интеграционных тестов?

У меня есть проект, который имеет:

  • Клиент JS с несколько интересным процессом сборки. Это включает в себя компиляцию CSS, привязку и минимизацию JS и CSS, создание и обработку HTML и некоторые другие шаги. Инструменты Node, такие как Grunt или Gulp, великолепны.
  • Сервер Java, который является WAR, развернутым на Tomcat. Он включает в себя эти активы, а также весь код Java. Он имеет всевозможные тесты: модульные тесты, интеграционные тесты, которые могут создавать DAO и говорить с БД, и сквозные тесты API, которые на самом деле говорят с приложением, работающим на Tomcat.
  • Полноценные тесты с помощью Протрактор. Если вы не знакомы, это еще один инструмент Node, который обертывает Selenium.

Как я могу организовать весь этот процесс разумным, надежным и автоматическим способом?

В настоящее время у меня есть Gulp и Maven, причем Maven в основном владеет всем процессом.

  • Он вызывает создание Gulp генерации ресурсов в источниках генерации с использованием antrun (doh, третий инструмент построения!).
  • Он запускает регулярную сборку Java.
  • Он запускает Tomcat с моей WAR в процессе предварительной интеграции.
  • Он запускает тесты Java E2E, разговаривая с этим tomcat с отказоустойчивым плагином.
  • Он снова вызывает Gulp с помощью antrun, на этот раз для запуска тестов Protractor.
  • Он отключает Tomcat в тесте после интеграции.
  • Предполагается проверить результаты проверки.

Подобные работы, за исключением того, что Maven, как правило, очень жесткие, и я чувствую, что забираю его слишком далеко. Использование antrun для вызова Gulp - уродливый трюк. Очень сложно контролировать зависимости между этими шагами и контролировать их результаты. Трудно контролировать порядок вещей в той же фазе. Отказоустойчивая проверка не обрабатывает внешние файлы отчета JUnit, созданные Gulp. Я мог бы продолжить.

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

Итак, как бы вы его реализовали?

Ответы

Ответ 1

По моему опыту, плагин frontend maven - это далеко не лучший плагин для этого типа процесса сборки/развертывания. https://github.com/eirslett/frontend-maven-plugin. Вот как я использую его для Grunt, но он поддерживает Gulp так же хорошо.

<plugin>
    <groupId>com.github.eirslett</groupId>
    <artifactId>frontend-maven-plugin</artifactId>
    <version>...</version>

    <!-- optional -->
    <configuration>
        <workingDirectory>src/main/frontend</workingDirectory>
    </configuration>

   <execution>
    <id>grunt build</id>
    <goals>
        <goal>grunt</goal>
    </goals>

    <!-- optional: the default phase is "generate-resources" -->
    <phase>generate-resources</phase>

    <configuration>
        <!-- optional: if not specified, it will run Grunt default
        task (and you can remove this whole <configuration> section.) -->
        <arguments>build</arguments>
    </configuration>
</execution>
</plugin>

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

Ответ 2

Я бы попытался построить некий бедный человек.

  • Пусть grunt/ gulp выполняет свою работу в первую очередь (обрабатывать активы, запускать тесты интерфейса и т.д. - готовить артефакты для включения в WAR). Не удалось завершить сборку, когда этот шаг завершится неудачно (создание активов или тесты).

  • Запустите регулярную сборку maven, создающую WAR файл с активами, созданными на шаге 1. Он будет запускать собственный набор тестов только с регулярным WAR файлом. Не нужно знать о вещах grunt/ gulp.

У вас будет два места, где, например, тесты выполняются (frontend, run grunt/ gulp и backend by maven), но настройка правильных репортеров позволит CI-серверам обнаружить все из них (мы используем TeamCity, и он отлично справляется).

Script немного, и это должно быть лучше, чем вызов node через antrun несколько раз. В качестве альтернативы вы можете выполнить первый шаг изнутри сборки maven, но может быть трудно контролировать материал.

Ответ 3

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

Хотя я не согласен полностью с их процессом сборки, я вернусь, чтобы объяснить, почему и что я делаю в проектах, над которыми я сейчас работаю.

Ответ 4

Этот проект составляет около 2 лет, но он многое делает для вас.

https://github.com/pankajtandon/PointyPatient/blob/master/pointy-web/pom.xml

Выполните проверку родительского pom, который в основном запускает все подпроекты вместе с веб-сайтом в домене до репо и терпит неудачу, если нет (тесты Jasmine или SpringMVC или SpringServices). И он также создает войну для развертывания на стороне сервера.

Это был пред-транспортир, так что это было бы приятным дополнением. Altho плагин frontend maven теперь выглядит как инструмент для работы.

НТН Панкай