Этап качества кода с использованием Jenkins

В непрерывной доставке каждая сборка потенциально может быть отправлена. Этот факт подразумевает, помимо прочего, назначение версии ваших снимков без снимка как можно быстрее, чтобы вы могли ссылаться на них в течение всего процесса. Обычно автоматизированный процесс доставки программного обеспечения состоит из нескольких этапов, таких как этап фиксации, качество кода, приемочные тесты, ручное тестирование, развертывание и т. Д. Но давайте сосредоточимся на втором этапе, связанном с качеством кода. Обратите внимание, что в моем предыдущем посте ( http://www.lordofthejars.com/2013/02/conditional-buildstep-jenkins-plugin.html ) есть некоторые концепции, которые используются здесь.

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

(в основном возможный NPE ), условные обозначения кода или создание ненужных объектов. Некоторые из проектов, которые обычно используются, включают Checkstyle , PMD или FindBugs среди других. В этом случае мы увидим, как использовать Checkstyle , но, конечно, он очень похож на любой другой инструмент. Поэтому первое, что нужно сделать, — настроить Checkstyle на наш инструмент для сборки (в данном случае Maven ). Поскольку мы хотим запустить статический анализ только на втором этапе нашего конвейера, мы собираемся зарегистрировать плагин Checkstyle Maven в профиле метрик . Помните, что все плагины, запускаемые для анализа кода, должны быть добавлены в этот профиль.

Теперь, когда у нас настроен 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 metrics. И, наконец, чтобы лучше видеть результат, мы можем установить плагин Checkstyle Jenkins и опубликовать отчет. После установки плагина мы можем добавить новые Действия после сборки с именем « Опубликовать результат анализа Checkstyle ». В нашем случае отчет находится по адресу ** / target / checkstyle-result.xml .

И это все для текущего этапа, следующий этап отвечает за проведение приемочных испытаний, но это будет в другом посте. Итак, в итоге мы узнали, как после компиляции кода и выполнения некоторых тестов (на первом этапе конвейера) этап качества кода запускается в Jenkins с помощью плагина Checkstyle Maven .

Ссылка: этап качества кода с использованием Jenkins от нашего партнера JCG Алекса Сото в блоге One Jar To Rule All .