Developing a Continuous Integration (And Self-Testing) System

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:

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

Copyright © 1998 - 2019 Olenick. All Rights Reserved | Terms and Conditions
 
   

This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our use of cookies.

Please read our cookie policy for more information on the cookies we use. Olenick’s privacy policy is available here.

More information Ok Decline