Code Quality Stage Using Jenkins
Join the DZone community and get the full member experience.
Join For FreeIn Continuous Delivery each build is potentially shippable. This fact implies among a lot of other things, to assign a none snapshot version to your components as fast as possible so you can refer them through all the process.
Usually automated software delivery process consist of several stages like Commit stage, Code Quality, Acceptance Tests, Manual Test, Deployment, ... But let's focusing on second stage related to code quality. Note that in my previous post (http://www.lordofthejars.com/2013/02/conditional-buildstep-jenkins-plugin.html) there are some concepts that are being used here.
Second stage in continuous delivery is the code quality. This step is very important because is where we are running static code analysis for detecting possible defects (mostly possible NPE), code conventions or unnecessary object creation. Some of projects that are typically used are Checkstyle, PMD or FindBugs among others. In this case we are going to see how to use Checkstyle, but of course it is very similar in any other tool.
So the first thing to do is configure Checkstyle into our build tool (in this case Maven). Because we only want to run the static analysis in second stage of our pipeline we are going to register the Checkstyle Maven plugin into a metrics profile. Keep in mind that all plugins run for code analysis should be added into that profile.
<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>
Now that we have our pom configured with Checkstyle, we can configure Jenkins to run Code Quality stage after the first stage (explained in my previous post).
In this case we are going to use Trigger Parameterized Build plugin to execute code quality job from commit stage.
Because code of current build version has been pushed into a release branch (see myprevious post) during commit stage, we need to set branch name as parameter for the code quality Jenkins job, so code can be downloaded and then run the static analysis.
In build job of our first stage, we add a Post-build Action of type Trigger parameterized build on other projects. First we open the Configure menu of first build job of pipeline and we configure it so next build job of the pipeline (helloworld-code-quality) is executed only if current job is stable. Also we define theRELEASE_BRANCH_NAME parameter with branch name.
Then let's create a new build job that will be in charge of running static code analysis, we are going to name it helloworld-code-quality.
And we configure the new build job. First of all check the option "This build is parameterized", and add a String parameter and set the nameRELEASE_BRANCH_NAME. After that we can use RELEASE_BRANCH_NAME parameter in current job. So at Source Code Management section we add the repository URL and in Branches to build we set origin/${RELEASE_BRANCH_NAME}.
Then at Build section we add a Maven build step, which executes Checkstyle goal:checkstyle:checkstyle -P metrics.
And finally to have a better visibility of the result, we can install Checkstyle Jenkins plugin and publish the report. After plugin is installed, we can add a new Post-build Actions with name "Publish Checkstyle analysis result". In our case report is located at**/target/checkstyle-result.xml.
And that's all for current stage, next stage is the responsible of executing the acceptance tests, but this would be in another post.
So in summary we have learned how after code is compiled and some tests are executed (in first stage of pipeline), the Code Quality stage is run into Jenkins usingCheckstyle Maven plugin.
In this case we are going to use Trigger Parameterized Build plugin to execute code quality job from commit stage.
Because code of current build version has been pushed into a release branch (see myprevious post) during commit stage, we need to set branch name as parameter for the code quality Jenkins job, so code can be downloaded and then run the static analysis.
In build job of our first stage, we add a Post-build Action of type Trigger parameterized build on other projects. First we open the Configure menu of first build job of pipeline and we configure it so next build job of the pipeline (helloworld-code-quality) is executed only if current job is stable. Also we define theRELEASE_BRANCH_NAME parameter with branch name.
Then let's create a new build job that will be in charge of running static code analysis, we are going to name it helloworld-code-quality.
And we configure the new build job. First of all check the option "This build is parameterized", and add a String parameter and set the nameRELEASE_BRANCH_NAME. After that we can use RELEASE_BRANCH_NAME parameter in current job. So at Source Code Management section we add the repository URL and in Branches to build we set origin/${RELEASE_BRANCH_NAME}.
Then at Build section we add a Maven build step, which executes Checkstyle goal:checkstyle:checkstyle -P metrics.
And finally to have a better visibility of the result, we can install Checkstyle Jenkins plugin and publish the report. After plugin is installed, we can add a new Post-build Actions with name "Publish Checkstyle analysis result". In our case report is located at**/target/checkstyle-result.xml.
And that's all for current stage, next stage is the responsible of executing the acceptance tests, but this would be in another post.
So in summary we have learned how after code is compiled and some tests are executed (in first stage of pipeline), the Code Quality stage is run into Jenkins usingCheckstyle Maven plugin.
Continuous Integration/Deployment
Jenkins (software)
career
Checkstyle
Published at DZone with permission of Alex Soto, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
-
RBAC With API Gateway and Open Policy Agent (OPA)
-
Microservices With Apache Camel and Quarkus
-
What ChatGPT Needs Is Context
Comments