Thursday, May 23, 2013

Continuous Integration and Code Quality Tools - Part 2

Before I start off - CI actually means building the artifacts and testing them as well. You can run unit tests, integration and smoke tests as part of your Jenkins job.CI can be best suited to a Agile model where a daily/weekly build is necessary. CI is also useful for very huge projects in continuous development but I would not really recommend it for small projects which is for a one time release.

 So once we had the CI (Jenkins) setup and performing all our required builds, it was time for us to investigate into quality check tools. The first thing which we looked into was Unit testing - JUnit and TestNG. Junit is the widely used testing tool in Java and has been evolving all these years. TestNG on the other hand is a very strong flexible multipurpose testing framework. Wiki quotes it as "It uses Annotations since first version and is a framework more powerful and easy to use than the most used testing tool in Java: JUnit". TestNG even has a migration plugin with eclipse to migrate from Junit ;)

The next tool which we had our eyes on was something which could measure the code and branch coverage. JaCoCo, Clover and Corbetura were the competitors. Clover requires to instrument the source code,  Corbetura instruments the code offline where as JaCoCo allows to instrument the bytecode while running the code. In addition, JaCoCo is the only coverage tool which works completely with Java7. The next question for us was to determine the percentage which we want as standard. Industry standard by word of mouth is to have 50% code coverage because there would be only 50% of code which has some logic in them - the rest being DTOs..etc

The other question which we had, was to find a tool which makes sure that the Java Coding Standards are met. We looked at PMD and Checkstyle. Checkstyle checks the style of coding alone where as PMD on the other hand will point out questionable coding standards which is a bit more relevant. Researching on those tools, we also came upon Findbugs which is much more relevant and useful. This checks not just the style but also bad coding practices and unsafe code.

We did setup all these tool plugins and Jenkins and had quite some good success with it. That is when we stumbled upon Sonar. This tool did blow up our minds - it is a mix of all these tools mentioned above and more. In addition to these we could more plugins to it. Integration to Jenkins server was as simple as running an installation package. Sonar also provided a war file which can be deployed onto a web server. However, it performs better when connected to a actual RDBS rather than the embedded one. The tool runs all the different tools and generates a web dashboard which is quite intuitive. Sonar also provides a plugin for eclipse based platforms which is an additional advantage. The rules can be configured/customized in Sonar to suit needs of each of the project or the organization. Sonar does more than just running these tools for you, it can give you changes in improvements to the code after the change and costs for fixing some changes. Sonar Jenkins combination is a killer :)

Continuous Integration and Code Quality Tools - Part 1

There has been lot of hype around this topic in my company. This gave me a fairly good opportunity to meddle around and find some tools which helps maintain the quality of code and for Continuous Integration.

First of all, choosing tools for any purpose in any company does have their own needs and considerations. We had to look at tools which are basically opensource with good support from third party vendors. We looked through quite a number of CI tools which include Jenkins/Hudson and Apache Continuum. Jenkins was the chosen one after much discussions. The features which really kept it separate from the rest are its support to multiple build systems, wide range of plugins to communicate to variety of Code Quality tools, plugins for SVN, Sourcesafe and Rational Clearcase, multiple Notification mechanisms and most importantly plugin for Eclipse based platforms.

The Jenkins setup was relatively straight forward. All it needs is a web server (we stuck to JBoss as it was our infrastructure) where the Jenkins war file can be deployed. Creating jobs for a project, setting its dependencies, setting pre-build and post-build actions are very easy to create from the web UI. The Jenkins UI is pretty much self explanatory with its hints for each of the configs. We set our Jenkins up with mainly two different configurations. 
1. Ant build with access to Rational Clearcase
2. Maven 2 build with access to SVN.

Both these configurations have been working like a charm ever since we set them up.

We have also set up plugins to run JUnits, Findbugs, Corbetura and Checkstyle which are code quality tools. I will continue with them in the next part.