UPDATE: I noticed after initial publish the order of the clips in this episode where very incorrect. I've now updated - apologies for any confusion. In last week's episode I started a mini-series introducing some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer. In that episode, I introduced Source Control, what it was, why your developers will be using it and the value it brings. Once your development team has saved their software code to the Source Control, what happens next? In this episode I introduce Continuous Integration.
Or listen at:
Published: Wed, 27 Nov 2019 16:38:28 GMT
Transcript
Wikipedia describe Continuous Integration as:
"continuous integration is the practice of merging all developers' working copies to a shared mainline several times a day"
Continuous Integration is part of a group of terms including Continuous Delivery and Continuous Deployment.
All three terms are involved in the continuous flow of software changes from the developer to the customer.
Each builds on the former - with Continuous Integration taking the Source Control as its starting point. Each moving the investment you have made in your development team writing software code into the hands of your customer where you can receive the benefit of that work.
In this episode I will focus on Continuous Integration.
Continuous Delivery and Continuous Deployment will be discussed in the next couple of episodes.
Let's start with the problem that Continuous Integration resolves.
When I first started with one client, I found that they had multiple developers making changes to the same website as part of different projects.
Each project would introduce some change to the website. They would designed, developed and tested in isolation. Commonly over many months.
Then every couple of months a deployment to that website would be made.
To do this, all the "ready" project changes would be packaged together ready for release.
Now each of those project changes had been designed, development and tested in isolation - but not together.
And this is where the fun started.
Commonly it would take an experienced senior developer 2 weeks to integrate those changes together. Not helped by the fact that original developers of the change will have moved onto another project or even left the organisation in the intervening time.
And that was just to get all those changes ready to be released.
What was then very common, was a whole host of errors being identified when the website went live.
While each change has been tested in isolation, they had not been tested together.
And unfortunately, many of those changes simply did not play well together.
Thus would generally follow a series of triage fixes to resolve those problems.
Again not helped by the progress of time; when the original developers will have moved onto other things - that is of course if you could even be confident which changes was actually causing the live issue.
Now the traditional method of resolving this would be to have introduced more testing once all the changes had been merged together.
Unfortunately, the testers, like the developers, will have moved onto other things.
So the effort to re-test everything was generally prohibitively high.
And in most cases the temptation to just "sneak" another critical change into an ever growing release became irresistible.
As more testing was required, releases became less frequent and more pressure was put on to get those critical changes in.
Ultimately this led to:
- Slow return on the investment made in the actual software development
- Expensive work to integrate the changes
- Expensive work to re-test those integrated changes
- And expensive work to mitigate the subsequent poor quality when it went into production
So how does Continuous Integration help with this?
As the name suggests, it is removing that delay between software changes being built and them being integrated together.
Under Continuous Integration we should be seeing developer changes been integrated many times a day - even when the work is incomplete.
This means that;
- We identify and fix any inconsistencies between changes much quicker - which makes them significantly cheaper to resolve as the developers are actively working on them and engaged
- Testing does not need to be repeated as we are testing based on the changes already having been merged together - again if one change is having an unexpected impact on another - the quicker we know about it - the cheaper it is to fix it
And ideally that testing is automated as I discussed in episode 14.
A quote from Martin Flower, a much respected thought leader in software development:
"Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove."
And this is ultimately what Continuous Integration is giving you - a more cost effective way of identifying software problems.
We acknowledge that software developers are human - they WILL make mistakes. They WILL be producing software bugs.
The key is to identifying those software problems as early as possible and as close as possible to the original developer - greatly reducing the cost and time to resolve.
This actually frees your developers up to do more. They spend less time fixing the bugs - giving them more time to produce additional value to the customer.
So how do we achieve Continuous Integration;
It starts with the development team committing their software code into the Source Code system.
An automated system then starts;
- It builds the new software code into the software program
- It runs the automated tests
If there is either a build problem or testing failure, then the team is alerted immediately - generally being alerted within minutes - certainly quick enough that they are still in the same mental space.
And that's pretty much it.
This may seem amazingly simple, but it is incredibly powerful to breakdown that high level of pain I discussed earlier into smaller bite size chunks.
Key to realising the value is that the development team must observe certain rituals;
Firstly, if the Continuous Integration system finds a problem it must be resolved immediately. If the build or automated test fails it can be easy to leave it to someone else.
Doing this however means you could quickly build more problems on top of it. Potentially obscuring the original issue and making it much more complex (and thus expensive) to identify and resolve.
Left unattended, I've seen teams completely ignore the results of a fails build or automated test as being normal - and quickly we are back to being in the same mess we started with.
Thus if the Continuous Integration system reports a problem, it should be jumped on as priority. And this includes being a much higher priority that going to lunch or going home. The Continuous Integration system must always be in a valid state.
Secondly, they must save their changes to the Source Control on a regular basis - ideally multiple times per day. The longer they leave their changes outside of the scrutiny of the Continuous Integration the larger the set of changes that will have to be merged back in. Again, putting us back to where we started.
Some developers are nervous do this with incomplete or unfinished code.
There are two approaches to address this;
Keep the changes as small as possible and disabled any incomplete functions.
Keeping the changes small is a good practice anyway - this aligns with how I've previously talked about Minimum Viable Product. We really shouldn't be thinking about a change being many months long. Rather we should be thinking about many small changes that take us towards the bigger objective.
And by disabling any of those small changes, we can ensure that they don't affect the production operation - but we still get the benefits of the Continuous Integration practice. I'm planning to cover techniques to handle incomplete work in episode 22 in about 3 weeks time.
Again similar to Source Control, there will be a costs associated with setting up and operating the Continuous Integration.
There will be the effort to setup it up in the first place - for which you can generally see payback very quickly.
Generally I'd expect this to be a few hours to a few days worth of setup dependant on how experienced the Software Team is with doing it.
There will also likely be some spend on a system to provide the Continuous Integration - be that software licences, physical machines to build or cloud costs.
In most cases this is likely to be negligible as a cost - but can sometimes make Development Teams nervous about asking for.
The actual costs will be dependant very much on your individual environment - including factors such as the size of the software, the architectural complexity, the amount of automated tests and how quickly you want that feedback.
In this podcast I continued this mini-series introducing some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer.
I've introduced Continuous Integration as the step that takes software code from the Source Control, performs an automated build and runs the automated unit tests.
I've described the problems that Continuous Integration addresses - along with the benefits of fast feedback on the overall development effort.
I've also talked about some of the developer rituals that need to be observed to ensure that the Continuous Integration is utilised.