В непрерывной доставке каждая сборка потенциально может быть отправлена. Этот факт подразумевает, помимо прочего, назначение версии ваших снимков без снимка как можно быстрее, чтобы вы могли ссылаться на них в течение всего процесса.
Обычно автоматизированный процесс доставки программного обеспечения состоит из нескольких этапов, таких как
этап фиксации, качество кода, приемочные тесты, ручное тестирование, развертывание и т. Д. Но давайте сосредоточимся на втором этапе, связанном с качеством кода. Обратите внимание, что в моем предыдущем посте (
http://www.lordofthejars.com/2013/02/conditional-buildstep-jenkins-plugin.html ) есть некоторые концепции, которые используются здесь.
непрерывной доставки является качество кода. Этот шаг очень важен, потому что здесь мы выполняем статический анализ кода для обнаружения возможных дефектов (в основном возможных
NPE ), соглашений о коде или создания ненужных объектов. Некоторые из проектов, которые обычно используются, включают
Checkstyle ,
PMD или
FindBugs среди других. В этом случае мы увидим, как использовать
Checkstyle , но, конечно, он очень похож на любой другой инструмент.
Поэтому первое, что нужно сделать, — настроить
Checkstyle на наш инструмент для сборки (в данном случае
Maven ). Поскольку мы хотим запустить статический анализ только на втором этапе нашего конвейера, мы собираемся зарегистрировать
плагин Checkstyle Maven в
профиле метрик . Помните, что все плагины, запускаемые для анализа кода, должны быть добавлены в этот профиль.
<profiles>
<profile>
<id>metrics</id>
<build>
<plugins>
<!-- CHECKSTYLE -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.9.1</version>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Теперь, когда у нас
настроен pom с
Checkstyle , мы можем настроить
Jenkins для запуска
этапа качества кода после первого этапа (объяснение в моем
предыдущем посте).
В этом случае мы будем использовать
плагин Trigger Parameterized Build, чтобы выполнить задание качества кода на этапе фиксации.
Поскольку код текущей версии сборки был помещен в ветку релиза (см. Мой
предыдущий пост) на этапе фиксации, нам нужно установить имя ветви в качестве параметра для задания качества Jenkins качества кода
, чтобы код можно было загрузить, а затем запустить статический анализ.
В сборке нашего первого этапа мы добавляем
После сборки Действие типа
триггера параметрироваться сборки на другие проекты . Сначала мы открываем
меню « Конфигурация» первого задания сборки конвейера и настраиваем его так, чтобы следующее задание сборки конвейера (
helloworld-code-quality ) выполнялось, только если текущее задание стабильно. Также мы определяем
параметр RELEASE_BRANCH_NAME с именем ветви.
Затем давайте создадим новое задание на сборку, которое будет отвечать за выполнение статического анализа кода, назовем его
helloworld-code-quality .
И мы настраиваем новое задание на сборку. Прежде всего, проверьте параметр «
Эта сборка параметризована », добавьте
параметр String и задайте имя
RELEASE_BRANCH_NAME . После этого мы можем использовать
параметр RELEASE_BRANCH_NAME в текущей работе. Поэтому в
разделе « Управление исходным кодом » мы добавляем URL-адрес хранилища, а в
разделе «
Ветви» мы устанавливаем
origin / $ {RELEASE_BRANCH_NAME} .
Затем в
разделе Build мы добавляем
Maven шаг сборки, который выполняет
Checkstyle цели:
Checkstyle: Checkstyle метрики -P.
И, наконец, чтобы лучше видеть результат, мы можем установить
плагин Checkstyle Jenkins и опубликовать отчет. После того, как плагин установлен, мы можем добавить новые
Действия после сборки с именем «
Опубликовать результат анализа Checkstyle ». В нашем случае отчет находится по адресу
** / target / checkstyle-result.xml .
И это все для текущего этапа, следующий этап отвечает за проведение приемочных испытаний, но это будет в другом посте.
Итак, в итоге мы узнали, как после компиляции кода и выполнения некоторых тестов (на первом этапе конвейера) этап качества кода запускается в
Jenkins с
помощью плагина Checkstyle Maven .