Code Quality stage using Jenkins

In 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.

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 my previous 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 the RELEASE_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 name RELEASE_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 using Checkstyle Maven plugin.

We keep learning,
Alex

En algun lugar de un gran pais, Olvidaron construir, Un hogar donde no queme el sol, Y al nacer no haya que morir… (En Algún Lugar - Dunncan Dhu)

Music: http://www.youtube.com/watch?v=Myn7ghLQltI

The Reality of Developer's Life

In this post I am going to try to illustrate in a funny way the reality of developer's life. This post is a translation of another post written in Spanish.

When you upload something to production environment:

When you find a problem solution without searching in Google:

When you close your IDE without saving the code:

When you try to fix a bug at 3AM:

When your regular expression returns what you expect it:

When my boss reported me that the module I have been working will never be used:

When I show to my boss that I have fixed a bug:

When I upload a code without tests and it works as expected:

When marketing folks show to developers what they have sold:

The first time you apply a CSS to a web page:

When the sysadmin gives you root access:

When you run your script the first time after several hours working on it:

When you go on weekend and everyone else are at office trying to fix all issues:

When your boss finds someone to fix a critical bug:

When you receive an extra paid if project ends before deadline:

When something that had worked on Friday and on Monday did not work:

When you develop without specifications:

When boss tells me that "tests are for those who doesn't know how to code":

When you update a database script and you note that you have deleted whole database:

Have you ever life one of these experiences? I hope so :D, if not maybe you are not a real developer ;)

PD: Original Source In Spanish

Conditional BuildStep Jenkins Plugin for Improving Continuous Delivery decisions.

In 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 the first stage. 

The first stage can contain next steps:

• create a release branch
• assign a version to the project
• compile + testing
• packaging (create a war, jar, ...)

But during the execution of one of these steps, a fail may occurs, for example code does not compile or some tests does not pass, and in this case we should delete the created release branch and stop the pipeline execution. On the other hand, if this stage ends successfully, Jenkins should run the next stage defined in pipeline.

To take this decision we are going to use Conditional BuildStep plugin, which as its name suggests, it allows us to choose which actions to fire depending on result of current job.

So after plugin is installed, we can create a job for the first stage:

So first of all, let's add a new build step (Execute Windows batch command or Execute shell) and launch a git command for creating a branch:

git checkout -b helloworld-release-%VERSION_NUMBER%.%BUILD_NUMBER%

In this case we are creating a branch with name of the project, the version number and finally the build number (which is provided by Jenkins).

Next step is to change the version of pom files (keep in mind that we are changing poms of branched project, not the "master") to current version. So let's create a new build step of type "Invoke top-level Maven targets" to invoke Versions Maven plugin.

versions:set -DnewVersion=%VERSION_NUMBER%.%BUILD_NUMBER%

Then we can call the clean install goals in a new build step.

clean install

Now is where Conditional BuildStep plugin starts to play:

If current build status is success, which means that code has been compiled and all tests pass, then we must commit the changes and pushing them to remote SCM server.

So let's create a new build step called Conditional Step (single), and set that if build status is successful, git commands are executed.

But if build fails, the branch should be removed, so let's create a new conditional build step in the same build job, which will remove the created branch from current location:

We have learned how to use Conditional BuildStep plugin to take decisions depending on the status of the current build.

We keep learning,
Alex.

PD: Although I am using this approach successfully in my projects, it is based on John Smart presentation.

The bugle sounds, the charge begins, But on this battlefield, no one wins, The smell of acrid smoke and horses' breath, As I plunge on into certain death, oh, oh (The Trooper - Iron Maiden)

Music: http://www.youtube.com/watch?v=dTaD9cd8hvw

NoSQLUnit 0.7.4 Released

NoSQLUnit is a JUnit extension to make writing unit and integration tests of systems that use NoSQL backend easier. Visit official page for more information.

In 0.7.4 release, next changes has been added:

• Support for testing Replica Sets in MongoDB. (https://github.com/lordofthejars/nosql-unit#replica-set)
• Support for testing Shards in MongoDB. (https://github.com/lordofthejars/nosql-unit#sharding)
• Support for testing Replicated Sharded Cluster in MongoDB. (https://github.com/lordofthejars/nosql-unit#replicated-sharded-cluster)
• Added index support for GraphML datasets. (https://github.com/lordofthejars/nosql-unit#dataset-format-1)
• Updated documentation for using ISODate in MongoDB. Thanks to Denis Vergnes.
• You can set port when creating a default connection. Issue #49, thanks to Joel Costigliola.

We keep learning,
Alex.

I laughed at love cause I thought it was funny, but you came along and moooooved me honey, I've changed my mind, This love is fine (Great Balls Of Fire - Jerry Lee Lewis)

Music: http://www.youtube.com/watch?v=7IjgZGhHrYY

NoSQLUnit Forge Plugin is Forged

NoSQLUnit is a JUnit extension to make writing unit and integration tests of systems that use NoSQL backend easier.

Forge is a core framework and next-generation shell for tooling and automation at a command line level.

With NoSQLUnit Forge Plugin we can use Forge to create tests for NoSQL databases using NoSQLUnit.

This plugin we can create three kind of tests depending on the lifecycle that is required:

• Embedded: typically used in unit testing which starts an embedded instance of required database (not supported by all engines).
• Managed: usually used during integration or high level tests, which starts a remote instance in the same computer where tests are run.
• Remote: which uses already run database instances, usually in remote computers.

In current version of plugin, it supports next databases:

• MongoDB
• Neo4j
• Redis
• Cassandra
• HBase
• Infinispan
• CouchDB

When we execute the main command of this plugin, one JUnit test configured with NoSQLUnit features and one dataset file will be created.

Moreover the created test will contain one method for each public method of development class under test.

The main command is nosqlunit. Then the lifecycle, which can be embedded, managed or remote. And finally depending on the chosen lifecycle some the arguments.

The common arguments are:

• engine: we choose which database engine we want to use.
• databaseName: we set the name of the database under test.
• classname: we set the name of the test class created by the plugin.
• classUnderTest: full class name of the class we want to write a test.

Embedded

There is no special arguments

Managed

• path: home directory where NoSQL database is installed.

Remote

• host: server address.
• port: server port.

So for example a valid command will be:

nosqlunit managed --engine MONGODB --path /opt/mongo --databaseName test --classname MyTest --classUnderTest com.example.MyClass.java

And it creates MyTest test class under /src/test/java/com/example and a dataset file in /src/test/resources/com/example.

As almost all Forge plugins, you can install NoSQLUnit Forge Plugin by calling forge find-plugin nosqlunit and  forge install-plugin nosqlunit.

And finally remember that you can play with TAB to make your life easier.

We keep learning,

Alex.

Poder jugar al cel, això és un amor, I sentir el porc grunyir fort. Això ja no, quin horror!  (Dr Slump)

Music: http://www.youtube.com/watch?v=ts1J4lGexcg