Utilising Continuous Integration

When I came into my current role, we had our repository hooked up to Jenkins. Every time we would commit, it would build the code and run our unit tests. We'd know almost right away if someone had broken the build.

Yet if we wanted to deploy, that was a manual process. Someone would download the EAR and manually log into the Test environment to upload it. Continuous deployment was deemed a bad idea as it would disrupt testing, but there was no good reason to keep it as a manual process. Not least that the power to deploy was limited to a couple of people.

In our new setup, we have three deployment jobs:

1. Branches - builds a maven deploy up to the unit tests, and informs Bitbucket of the results.
2. Master - builds the master branch and stores the artifact on Archiva.
3. Deploy - takes the last successful build and deploys it to the Test server.

The first two are automatic and will run whenever there is a code change. The Branches job is integrated into our code review process, as Bitbucket is configured to only allow merging upon success. The Master job ensures we always have a potentially deployable artefact.

The Deploy job is manual, and controlled by the testing team, who run it whenever they are ready for more features to be tested. This gives the advantage that testers decide when they are ready for new work.

This doesn't solve all deployment problems. Any intervention with databases is manual. The necessity to deploy shared EARs is invisible to the testers and requires intervention on our part. And deploying to hither environments involves the cumbersome change management process. However, it's important to recognise all the wins the current setup gives us over what was there before.