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
No comments:
Post a Comment