Continuous Product

As developers were not used to being part of a production line but what if when we merged in our latest and greatest code a shiny new product came rolling off the line.

By applying continuous integration we can ensure a never-ending pipeline of product. 

Continuous Everything

Having our code being built frequently and automatically leads to several benefits, continuous integration first got its name because it was able to ease the nightmare of integration hell when prior to a release developers who had been working in isolation all of a sudden had to make their code play nicely together.

By continually testing, measuring and running our code we can apply a process of continuous quality that is feeding back metrics of the quality and health of our product, this gives us a warm feeling inside but also enables us to jump on issues as they happen rather than having a nasty surprise when customers get their hands on it.

By having our code base be the result of small pieces of effort being frequently added to the whole we can have continuous product where we are always in a position to be able to ship the latest and greatest to the customer. A key trait of agile is to deliver to your customers early and often, you can't get earlier or more often then automatically.

Building the Production Line

A continuous integration strategy should have certain key traits in order to reap the benefits automation can bring.

• Build Everything.
• Test Everything.
• Report Everything.
• Fix Everything.

Every commit into the main branch of a product should be built automatically; this build should be fast and easily configurable. Not every merge is going to go flawlessly but the sooner the problem is known the better.

Every build should be tested, you may have unit tests, functional tests and integration tests, some of which will take longer than others but at the very least every build should come with a stamp of approval that it does what it says in the tin.

The results of every build should be visible to everyone; this doesn't just mean the developers but everyone who has a vested interest in seeing a successful product.

Whenever a build produces any problems, whether they are integration problems, broken tests or quality issues they should be fixed at the earliest possible opportunity. The instant a team becomes used to a build being broken all the benefits of continuous integration are lost, if it is a problem you genuinely don't care about then it shouldn't be part of the build. The health of the build and therefore the health of the product should be the top priority on everyone’s list.

Rather than a working build of your software being a future goal somewhere down the road make it a continual output of the work your doing and keep your customers and stakeholders happy on a continual basis automatically.