Developing a Continuous Integration (And Self-Testing) System

continuous integration written on 2 gears


When you have multiple developers working on a project, bugs can be hard to pin down.

When was the bug introduced? Whose code was it? Did our merge introduce issues? Tracking down these kind of questions gets increasingly complicated – and costly – as you add more collaborators.

 

The Solution? Continuous Integration.

Continuous Integration (CI) is a software-building paradigm that tackles some of the complications of many development teams. Some key features of CI include:

  • Maintaining a repository
  • Developers commit to a baseline branch OFTEN
  • Automatic Builds on baseline commit
  • Automatic Testing on each build
  • Automatic Deployment

 

There is a lot here that is ‘Automatic’, and that’s why it’s a big deal. From a cost analysis perspective, any job that can be done by a computer, should be done by a computer. They are cheaper, much faster, and don’t get bored of repetitive work.

 

In the case of CI, our system will automatically build the application, run unit-level tests, and deploy it to production. And when we’re talking about doing this on every commit – which we do OFTEN – this saves a ton of man hours for developers and testers.

 

So, the merit is there. Now how do we do it? In a recent Olenick project, we implemented a system that covers all of the core CI bases.

 

Here’s what we did:

First, we chose a Continuous Integration service. There are many names out there, but we decided to go with a freemium service called ‘Wercker’, which has a lot of power. After spending some time setting up some Git hooks, this is what our build history looked like:

 

Wercker Interface

 

Pretty sweet, right? Every time code was committed to our mainline branch, Wercker would build, run unit tests, and deploy the application to our hosting environment. If something went wrong, the build would go red, halt deployment, and send the developers email alerts. Then we could track down the commit that broke, figure out what was going on and fix it.

 

And that’s the power: we didn’t use testing hours to find the bug, we didn’t send a broken application into production, and we didn’t spend hours trying to figure out the exact moment where a bug was introduced.

 

Running a strong CI system (together with good VC and unit test practices) can save a project time, money, and – most importantly – developer headache 🙂

 

There’s a lot of power in automation!

 

Further Reading on CI:

Good Version Control Practices

http://www.git-tower.com/learn/git/ebook/command-line/appendix/best-practices

Good Unit Test Practices

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

Wercker

http://devcenter.wercker.com/learn/

 

By John Gregory, Consultant – Olenick, Chicago


Related Content: Data Migration and ETL Testing, DevOps, DevOps, Microsoft Azure, Quality & Testing, Software Development - Application, System Integration