An (almost) free Continuous {Integration|Deployment|Delivery} Environment

When I started to work on janedoe (random data as a service) I did not want to host any of the required tools on my own. Why? It really hurts to maintain tools for a project on which you don’t work constantly. The need for an urgent patch always arises when it is least expected and most inconvenient.
Why Continuous {Integration|Deployment|Delivery}? I think that the borders between these three things are fluent and many people are using them without a clear definition of what they are really doing.

What I wanted is:

• Of course a hosted version control system and a build server which executes my unit and integration tests after every commit.
• Automated deployment to a test environment after every commit.
• Automated tests against this deployment after every commit. I’ve seen it in so many projects that a deployment was „successful“ but nobody cared if the app is really running.
• An easy way to release my application and deploy it to the production environment with a click of a button. This step should of course include all the pre and post tests like in the test environment.
• A code quality tool that generates reports after every commit.
• Monitoring of all environments. From my experiences the chances that a test environment is monitored are really low for projects on which you don’t work constantly. So the chances that your test environment is down when you start on your next feature are high. And even better: nobody knows who broke it accidentally weeks ago…

What I did not want is:

• Setting up new environments with a click of a button for instance via Puppet or Chef. I don’t need more environments in the near future. Also: janedoe is a dropwizard app including all configuration so all I need for a new environment is a Java Runtime and some environment variables. Should be easy to set up manually.

One more goal was to get everything for free or at least as cheap as possible. As janedoe is not Open Source the choices are quite limited. Great tools like GitHub or Travis CI are free for Open Source projects but elsewise not.

Runtime Environment

Let’s start with the runtime environment. Unsurprisingly something where you won’t find a free 24/7 environment. As I don’t want to care about OS or Java updates a „real“ server or hosted docker container is no option. Googles App Engine does not work well with dropwizard so I’ve chosen Heroku and was positively surprised how easy it is to run a dropwizard app here. A few settings and a Procfile and your app is up and running.
One dyno is free and sufficient for my test environment. The problem is that this dyno sleeps at least six hours per day. No problem for testing but monitoring does not make much sense. The never sleeping dynos start at $7 per month.

Source Code Management

Bitbucket is usually my choice if I need a free private repository. Most of you will know it but for those who don’t: Bitbucket is quite similar to GitHub and operated by Atlassian (the company behind JIRA and Confluence). Their pricing model is different to the one of GitHub: Private repos are also free as long as you don’t have more than five users.

Automated Workflow

The heart of the environment is running on Codeship. Codeship has a free plan including 100 builds per month. This should be enough for a hobby project even if you waste a lot of builds for the initial setup like me. Getting started is really easy. It takes just a few clicks to connect your repo and a few lines of configuration to run your tests automatically after every commit. In contrast to the way most of my other projects are configured on Jenkins you won’t find a release or deploy button on Codeship. The philosophy is executing tests after every commit and all other deployment pipelines are triggered by the commit of a certain branch. So if I push my development branch I trigger a deployment to test whereas pushing master triggers a release and a deployment to production. This is quite developer centric and fits for my project but I’m unsure if I would like this for bigger projects. Not uncommonly you’ll find more environments then test and prod like integration, qa, stresstest, pre-production and so on. Usually you’ll release once and deploy the released artifact to different environments at different times. These deployments should not build the project and execute tests again. One way to solve it could be some kind of meta-project which fetches and deploys the released app.
The thing that impressed me the most about Codeship was this:

failed Codeship build

Yes, this is true. This is a failed build and Codeship displays hints how you can possibly fix it. Awesome! For another problem I had to contact the Codeship support. They answered 2 hours later with a working solution for someone using their free plan. Priceless!

Release

The most interesting part was releasing the application. Heroku itself releases out of the box. In fact every deployment is a numbered release and you can easily rollback. The released version does not only contain the sources but also the configuration like for instance environment variables. So far so good but coming from the maven world I wanted a release that guarantees that there are no SNAPSHOT dependencies in my project, the release version matches the version in my pom.xml and so on.
Wagon-git makes it easy to use Bitbucket as your private maven repository and host your released artifacts but the problem is how do you get this release deployed to Heroku? It’s easy to check out the latest tag after the maven release and deploy this tag but Heroku will build your project again. I think this is ok for my hobby project but in other cases you’ll need some kind of meta project which just delivers a released artifact.

Monitoring

Dropwizard strongly recommends that all of your applications have at least a minimal set of health checks. And if you have them you should also monitor them and get some notification if a check goes red. Uptimerobot offers 50 monitors and checks every 5 minutes for free. Their slogan is “Start Monitoring (in 30 secs)” and they are right. It could not be easier, it could not be faster.

Code Quality Management

It was unforeseen hard to find a hosted SonarQube service. If you have an Open Source project you can request on the user mailing list if they add your project to nemo.sonarcube.org. CloudBees is providing it as part of their DEV@Cloud service but pricing starts at $60 per month. I did not find a hosted SonarCube with a freemium plan. I think this is really missing and the software world would be a better place if using SonarQube for every project would be so naturally and easy as using GitHub oder Heroku.
I had no other choice here then running SonarQube on my own server. It’s quite simple using the docker images but not what I wanted.

Conclusion

All in all I’m quite content. I’ve seen worse setups in “professional” projects. This proves that there’s no excuse for not setting up some kind of CI/CD environment even for hobby projects. The time you need for the setup will be refunded when you release and deploy your application a few times.