In the last few episodes I've 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 episode 18, 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, I then introduced Continuous Integration in the last episode, episode 19. I described how Continuous Integration allowed us to find problems faster - allowing us to address them much more cost effectively and making Software Development much more productive. In this episode I introduce the next step in the process of getting that software into the hands of your customer - Continuous Delivery
Or listen at:
Published: Wed, 04 Dec 2019 17:00:33 GMT
Transcript
Wikipedia describes Continuous Delivery as:
"Continuous delivery is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery."
Continuous Delivery builds on the automated build and running of automated tests provided by Continuous Integration and allows us to release that software at the push of a button.
We should feel confident that, given that our software has successfully built and been tested by our automation tests (thanks to the Continuous Integration), our software can be deployed to our customer.
It is then our decision to decide if that is the correct action.
The key difference between Continuous Integration and Continuous Delivery is being able to deploy our software on a button press.
If we want to deploy our software to a test environment for review or even to production, it should be as simple as a button press.
It should be effectively a non-event.
It should be easy and a routine event.
This may seem like a fairly innocuous distinction to some ... But the release of software, even to testing environments, can often be seen as a major event in a lot of organisations.
Its not uncommon to find that many of the actions to release our software are manual.
Potentially split across teams - involving server, network and database specialists.
Add in a desire to implement segregation of duties as a risk reduction technique - where the original developers are not allowed to actively be part of production deployment - thus resulting in pages and pages of easy mis-interpreted documented steps for other teams to carry out.
Ultimately , its no surprise that I'm still coming across organisation that are struggling to feel confident about releasing their software.
And as I've commented on previously, anytime that we lack confidence we have traditionally added more bureaucracy - which while well meaning, is resulting in further dysfunctions.
So how do we get out of that a dysfunctional cycle?
Jez Humble who literally wrote the "Continuous Delivery" book says
"If it hurts, do it more frequently, and bring the pain forward."
And this is a mantra that has stuck within the Continuous and DevOps practices.
While our normal human reaction is to avoid things that are painful - to put them off - defer them, this mantra advocates the opposite.
So rather than releasing our software as a rare and scary event - we drill it, repeat it, making it better and easier. Making all participants in it more comfortable with the steps.
We refine it to the point that is a well understood and repeatable process.
And once we are happy with that, we then take it that next step and automate it.
If we are confident we understand how to release our software in a repeatable manner - then stop doing it manually - automate it and make it a button press.
Automation is our ultimate method of codifying the work to release our software. It demonstrates that we know exactly what needs to be done each and every time.
It fulfils that desire to have the confidence that we "could" release that software whenever we want.
In automating, we also benefit from greatly de-skilling the release.
Effectively anyone can do it.
Rather than needing to engage a team of highly skilled people to prepare, carry out and support the release - we can have confidence that our button press is performing a well understood and validated process.
We greatly reduce the overhead needed to schedule and coordinate those activities.
We also gain greater clarity from an audit perspective on who is doing what and when.
Where we may have traditionally looked to enforce segregation of duties as a means of reducing security risk - we can now how confidence in a well built out (and reviewed) set of automation tasks - along with a full audit trail of who change them and who initiated them.
Generally a much stronger place to be than reliance on adherence to manual process.
In this podcast, I've introduced Continuous Delivery.
I've talked about the benefits it provides in terms of:
- Less errors during deployment of our software
- Confidence in the repeatability of that deployment
- Free's up specialised people to carry it out (anyone can press the button)
- Greatly reduces the overhead in planning and all of the bureaucratic overhead we've introduced to give us fake confidence
- And we have a much better and more reliable audit trail of who made what change