So, you’ve been going agile for some time now. And you’re questioning if agile really is the way to go. Along came something else known as Continuous Delivery that seems to be the new bandwagon.
But, wait, what is Continuous Delivery?
If you still have questions about it, you may find your answers in this piece. Keep reading!
Continuous Delivery (CD) – Agile’s replacement?
Over the years, Agile has evolved to mean so many different things that it’s very hard to define what it actually means. Try asking three different people in your team or organization and you will definitely yield three different answers to what agile is and what it means.
It’s also hard to nail down what activities you do day-to-day are within the scope of agile.
- Is it agile to write stuff on post-its? Sometimes!
- Is it agile to visualize your work? Probably!
- Is my teams’ build process agile? Eeeermmmm….maybe?
Emergence of Continuous Delivery
It’s no wonder agile is beginning to take a backseat, because nobody can provide a clear answer as to WHAT it is and HOW you do it!
Developers, especially, find that when things are hard to define, they are useless and are thus discarded.
However, from the ashes of Agile, came a definable process which is supported by a growing community of developers for its ability to make life easier for them in the long run – the phoenix that is known as Continuous Delivery.
What is Continuous Delivery?
Jez Humble’s continuousdelivery.com defines CD thusly:
Continuous Delivery is the ability to get changes of all types – including new features, configuration, changes, bug fixes and experiments – into production, or into the hands of users, safely and quickly in a sustainable way.
Our goal is to make deployments – whether of a large-scale distributed system, a complex production environment, an embedded system, or an app – predictable, routine affairs that can be performed on demand.
We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus complete eliminate the integration, testing, and hardening phases that traditionally followed “dev complete”, as well as code freezes.
Continuous delivery: a holy grail?
This all sounds incredible. Unbelievable, even. Drama-free deployments are the holy grail for dev teams.
If you have ever worked with or near a development team, I’m sure you’ve seen them enter the dreaded crunch mode – that time near a release when everything that’s not quite done has to get finished along with all tasks related to building, packaging, testing and releasing before the software goes out the door.
It can be a nightmare.
Continuous Delivery promises to get rid of that stressful time. By using Continuous Delivery, you always have a fully-tested and working software product ready to deliver to the customer. Releasing it to the world should be a trivial matter, preferably just the press of a button and it’s out.
It’s routine, it’s predictable, it should be downright boring
Sounds amazing, right? So, let’s all do Continuous Delivery right now!
But, wait a minute…
You can ask almost any developer and get the same reply:
This stuff is actually very hard to do.
There is so much stuff in a normal team’s release process that is manual labor:
- Integrating the final stories
- Quality Assurance
- Writing last-minute tests
- Doing a final release build
- Sometimes submitting to a marketplace (like Google Play or Apple Store or others)
- the list goes on and on.
When doing CD, you want to automate all of the above, while also delivering top-quality software.
Some things are hard to automate and take a long time to get right, especially if you’re only releasing every four weeks or even more rarely.
Teams release only when required to – it’s a much rarer activity than other things the team does (i.e. code review, pairing, writing tests and testing). The loop is longer. And long loops mean less learning.
Does Continuous Delivery replace Agile/Scrum?
The Scrum framework makes very light requirement on how you release software or how frequently you do it.
One of the principles of agile software suggests is:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Continuous Delivery, on the other hand, makes this requirement:
It’s not enough to deliver working software frequently, you must be able to deliver software continuously.
Thus shortening the loop of software creating. Remember, shorter loops mean more learning. This dovetails Scrum quite nicely:
When teams come up to release time, many incorporate stories in the sprint that capture the work required to release the software.
Maybe its a complement instead of a replacement?
If you have spent time streamlining your delivery process to the point that these stories aren’t required, you can release without drama or friction on the day of the sprint’s end, thus saving you precious time your team can spend on valuable things, like foosball and NERF fights.
Continuous Delivery puts the focus on delivering software, and making that process as smooth and frictionless as possible – a topic that scrum and agile don’t delve into.
By putting this critical part of the software creation process on center stage, all sorts of improvements take place.
- You test things more rigorously
- You spend time to improve your staging and production environments to be able to accept new relases more easily
- You spend less time on building and more on providing value to users
It helps you surface problems in your delivery process and encourages you to fix them so that you can deliver quicker.
Continuous Delivery complements agile or scrum nicely, since neither specifies much on how to deliver software – and delivering quicker is definitely a worthy goal for any agile development team.