Monday, July 11, 2016

Using SonarQube in a Shared Docker Image to simplify Java code quality testing for teams - Part 1

As teams work to increase their speed to production, a discussion about code quality will inevitably come up. 

In many cases, development team members (even with production level tools in place) have difficulty checking code quality before checking code into a shared repository and have to wait to see results. 

This article seeks to provide a method to allow code quality checks using SonarQube to happen on the development station before having to check to the code into a code repository while also providing a consistent base Plugin­ set for team members. 

Although the procedure below gives a base set to start with for Java developers, it is provided as a guide to allow you to use a similar approach and build something that is perfect for your unique environment.

This is the first of several posts.

Part 1 - A Quick-Start to using SonarQube and docker on a developer workstation with no long-term data retention 

Part 2 - An extension of this procedure to a cloud based server (such as Digital Ocean) 

Part 3 - Some notes about storing data long-term into a database.

Important Notes:​

The Quick-Start procedure in this document launches a container on a workstation that is disposable and will not retain any data if re­-created.  
An understanding of docker installation and execution is implied.

Please consider firewall implications as source code may become available at port 9000 at your workstation.

Technology used:

Article Sections 

  • Quick­-Start (development station) 
  • Sample launchable Dockerfile and image


Using the shared Droplet instance from your workstation

docker run -d --name sonarqube -p 9000:9000 mikecaspar/docker_sonarqube

You should see the latest image download .... 

You will be able to confirm the server is running with the command: 

docker ps

It should show you something like this ... 

Notice that the SonarQube server starts at tcp port 9000.  You may need to make firewall adjustments. 

To get the local server to see it’s current information, use the Url: 


The default SonarQube instance will look like this:  

* Notice the red warning that data stored in this instance will not stay in the server after it has been restarted. 

To add your Java project to the local instance for current code quality information, go to your Java project directory (where you POM file is) and type: 

mvn sonar:sonar

By  default , the Sonar plugin looks for a local Sonar Server to store data. 

The sonar plugin will download from your configured sources, analyse your code with the currently configured rules and then store the results in the current temporary instance. 

Now, you can see your progress without the need to check your code into a repository first!

Go back to your web instance at http://localhost:9000 and you will see how your code quality is. 

This sample has a few hours of technical debt shown for presentation purposes ... 

 A more detailed view.. 

Sample launchable Dockerfile and image 

A sample Dockerfile is available at this git repository:

This repository could be used as is to launch containers without the need to create your own if you are happy with the settings in the repository. 

If you to make your own changes, feel free to fork or clone the repo.

The Dockerfile is available at 

The default admin userid is ​admin​

The default admin password is ​admin​

Thursday, July 7, 2016

Self-driving vehicles and test code coverage

As many of us know, a world of self-driving vehicles is coming quickly. These vehicles do this with computer software.

I'd like to share a thought with others to start a discussion.

I generally hesitate to ask for rules and procedures, but in this case, I feel our lives may depend on it.

Should we ask auto-manufacturers to provide some kind of metric about source code test coverage as a percentage for the self-driving portion of the source code?

I acknowledge that 100% test code coverage does not guarantee reliable software. I also feel personally certain that I don't want a vehicle driving me around that has no Unit Tests or automated tests as part of the development, build and test process.

I have seen too much in my career to expect this to be safe.

Why do I bring this to people's attention now?

Many people do not know that there is an ongoing discourse in the software industry relating to the delivery of features versus appropriately testing software. I won't talk about this here. Do an internet search on "Extreme Programming" or "Test Automation" as a place to start. You'll see how important testing is to software.

It is not uncommon to hear comments in the software industry such as "Oh, it will be fine, it can go out with that bug", or "we'll fix it later", or my least favourite....

"We don't have time to write tests. 
We need to get the feature out."

Personally, I don't want to let a vehicle drive me where the developers have been pressured (or the developers have decided on their own) to write code without tests. Not all companies or developers are this way! I do not intend on painting them with a big brush.

I want to be clear.  I have zero knowledge of any vehicle manufacturer acting irresponsibly to-date. I am just thinking about my future and I don't want this topic to come up when it's far too late for myself, family or friends.

I have been in the software business long enough to know that I have a responsibility to society to bring this up now.

There's no perfect answer to appropriate code coverage with tests, Please don't get that impression. 

All I ask of you is that we find a way to not let this important conversation just disappear.
Letting auto manufacturers (new and old) know we care about code quality for self-driving vehicles will already go a long way.

If you are in the self-driving car business, please consider this as an important topic. Even if you disagree, I'll be happy because at least you thought about it.

I think about it this way.. I am saving my own life.