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 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. Then, in the last episode, I introduced Continuous Delivery. It builds on Continuous Integration and make the releasing of our of software as easy as a button press. Through automation we make our release process a repeatable, reliable, easy, non-event process. In this episode, I introduce Continuous Deployment.
Or listen at:
Published: Wed, 11 Dec 2019 15:35:45 GMT
Transcript
Wikipedia describes "Continuous Deployment" as:
"Continuous deployment is a software engineering approach in which software functionalities are delivered frequently through automated deployments. Continuous Deployment contrasts with continuous delivery, a similar approach in which software functionalities are also frequently delivered and deemed to be potentially capable of being deployed but are actually not deployed."
The simplified summary of Continuous Deployment is that it is the same as Continuous Delivery - but there is no button press - our software is released automatically.
The removal of a manual step to put our software into production - that's it.
But that is a great over simplification;
To paraphrase, its ...
"one small step for deployment, one giant leap for an organisation"
The actual technical difference between Continuous Delivery and Deployment is relatively trivial.
The impact on an organisations culture can be huge.
And predominate amongst this is a perceived lack of control.
Continuous Delivery requires a manual action to release the software ... Someone need to press the button.
As such an organisation can derive a sense of control by implementing a level of bureaucracy around the approval to allow someone to press that button.
Often I find that the bureaucracy is adding little if any real value - in fact, more often than not, due to the work that goes into coordinating and facilitating the bureaucracy I would actually suggest that it is actually a considerably poor return on investment.
Often these bureaucracies are little more than expecting someone to say they are aware of the change. And as there is little responsibility required - other than ticking a box - there is generally no greater control of risk achieved from it.
It is there purely to make an organisation feel comfortable that there is control in place - even though in practice there very rarely is.
But for all my logical arguments against the need, there is commonly still a strong emotional attachment to that control.
And this is why I treat it as a giant leap for an organisation.
Diluting perceived control is commonly a very difficult thing for an organisation - especially among the executive level.
I talked about some of the key cultural changes an organisation needs to be comfortable with back in episode 11.
And as per that episode, achieving it brings considerable step change to the organisation.
To have reached a state of Continuous Deployment, you will already have achieved a reliable and safe method of getting code from your development team to your customer.
You will have a reliable and safe method of storing your software code using Source Control.
You will have a reliable and safe method of validating that code changes are integrated together and validated against automated tests.
You will have a reliable and safe method of releasing those changes to the customer.
If you combine this then with post-release monitoring as I described in episode 15, you have a post-release safety net.
This gives you all of the technical capabilities to operate Continuous Deployment and achieve the benefits that come from it.
From Continuous Deployment you can achieve much faster delivery of value to your customer than just Continuous Integration or Delivery.
You are capable of having your development team make very small changes and get them to the customer many times a day.
This greatly increases throughput as all the effort is concentrated on getting a change to the customer.
The team can operate in the Minimum Viable Product style I described in episode 6. They can generate a theory and test it within minutes or hours rather than months or even years.
Risk is considerably reduced. The changes are small - thus greatly reducing the potentially for impact. The changes are active in the development teams mind - they are thinking about the same problem as the result is being put infront of the customer. They can react to the customer feedback or any problem immediately.
Contrast this code being released 6 months after it was developed. The cost to resolve or even investigate any problems is considerably inflated by that time delay.
And of course you have deferred gaining benefit from that investment for 6 months. That's going to be a poor return on your investment in anyone's book.
I've yet to find an organisation that doesn't want to achieve fast delivery of software change.
I've yet to find an executive that wouldn't dearly love to have an idea at 10am and have it being actively validated by real customers by 2pm and rolled out to the entire customer base by the end of the day.
That is the promise that Continuous Deployment can help you to achieve.
I'm not saying its easy or necessarily cheap to achieve - it certainly isn't something you can just buy (regardless of what some consultancies may claim).
I do however feel it is a worthwhile investment to make - both in cost and cultural change.
In this episode I've introduced Continuous Deployment. A step on from Continuous Delivery by automating the button press.
I've acknowledged that while this is a relatively trivial change from a technical perspective, it can be quite monumental from the organisational perspective.
And finally I've talked about the benefits that Continuous Deployment can help your organisation to achieve.