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

There is no such thing as a continuos integration server

Of course the title is reference to the “There is no such thing as a free lunch" adage, also known as TANSTAAFL, but really it is about the fact that people think they have the advantages of Continuous Integration when all they have is a build-server.
Of course this is just another instance of semantic diffusion, but IMHO there really is a huge opportunity wasted by not following the concept of continuous integration.

The original Continuous Integration

When I first came across the idea of continuous integration it was in the context of eXtreme Programming (XP). It was just a practice that required a lot of discipline, a finely tuned set of tests, a sound system architecture, capable developers and a good source code management system.

Low-tech is key

James Shore wrote a piece about “Continuous integration on a dollar a day” back in 2006, which in my regards still holds true even today.
The point here is in both cases – in the original description as well as in the James’ article –, that no task is done until it is incorporated in the “main development line” and it is shown that this main development line is proven to be as error-free as can be at that point in time. And the developer(s) who signed up for that task take it on as their responsibility to make it happen. To ensure that this is handled in an efficient way, integrations are serialized and don't happen concurrently. (James employs a nice token to ensure that)
Simple enough – not much technology needed.

Using this approach you end up with a product that always includes all the work completed at that point in time in a way that could be shipped or installed instantly.

That may sound nice in theory, but in our case...

• ... the tests run too long
• ... our tasks are so small, we would have way to much overhead
• ... out team is too big for that
• etc.

Fair points – let me address them one at a time:

The tests run too long?
That is a very good indicator to make your tests faster and perhaps more expressive. Or change your architecture in such a way that you have more, smaller, independently testable components.

The task are to small for that?
Create slghtly(!) bigger tasks

The team is too big for that?
Your team is too big. Period. Change that!

etc.?
If the CI-approach is not feasible because of «X» it is almost always a good indicator that you have a problem with «X» - even though the case of long running tests deserves a seperate discussion.

The Problem with CI-Servers

Don't get me wrong – I'm a big fan of automated builds and build servers. But my point ist that they just can't provide continuous integration.
being serious about continuous integration means you can never have a red build on the deliverable after a task is completed and integrated. After all making sure that the main line is “clean” is essential to the very definition of continuous integration.

The point of the original CI-concept is: As a developer your job is not done until the main line reflects your work

The point of the so-called ”CI-Servers“ is: “Just commit your current work an start on something new – I‘ll let you know some time in the future if the test still show that the software is okay or if there are any clashes with contributions from your co-workers.”

Therefore build-servers actually promote starting on new tasks before the seemingly finished tasks are completely integrated – that's exactly what they are made for...

And the problem gets worse if your tasks are small and the test are long-running... Then you end up with huge build queues that grow during the day and get cleared up at night. And it takes until the next morning until you get feedback on whether your code is really integrated with the system or you still have to do rework.

So yes, please use a build server – but only as a safety net. And don't call it continuous integration just because you have a server performing your build-runs and unit-tests for you.

’till next time
  Michael Mahlberg