What exactly is continuous integration?

A while ago I wrote about the fact, that a build server can't give you continuous integration, now let's look at what we might want to accomplish with continuous integration in an agile project.

Three stories and a potentially shippable product increment

Let us look at an example from a scrum-inspired project. Suppose we have three backlog items (of course not necessarily stories in the Cohn format...):

• our product can do ‘X’
• our product can be installed on Windows
• our product can be installed on Android

The ‘old’ way

In an old-fashioned project, using ‘late integration’ those requirement could easily be met by having three separate results

• a web-application where the ‘x’ can be demonstrated
• an install-package for Windows, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed
• an install-package for Android, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed

These different artifacts could even be put in the same source-code repository and built by some type of build server, but they would not have to interact with each other, because that could be part of a later integration phase.

The problem in this scenario is that there is no mandatory requirement for a functional integration between these tasks.

So you could end up with an installer on Windows that just displays some “this would be your application” boilerplate text, an install package for Android that contains a different launch mechanism than the windows version and a web application that can do ‘x’ but is included in neither.

Even if the automated tests related to each backlog item would be ‘green’ on the build server, the customer would still end up with three separate “features” that might not generate any value for them.

The agile way

Building this with a continuous integration mindset would be different. Following the old ideas of continuous integration in conjunction with the mindset of a potentially shippable product increment yields quite different results. Especially since such an increment contains all the existing functionality as usable and working software.

In this scenario we would focus on integrating the functionality and make sure that every story we complete interacts with all the other stories.

And all off a sudden, the customer would have real value – whether the artifacts are built via a build server or not. As long as the team creates a thing that really could be shipped every time it integrates a task – in the functional sense – and makes it easily accessible to the customer, the customer can just take that artifact(s) and interact with all of the currently completed functions.

No ci-server required, btw.

’till next time
  Michael Mahlberg