Introducing Continuos Delivery (CD) to software teams often leaves them either sceptic or at least with many question marks in their heads.
It may be surprising for some that we all knew and used it already for a long time. Somehow.
We always delivered continuously, somehow
Actually we never did anything else than release or deliver [1] software (except the few times we don’t wanted to or the products were cancelled). We developed it, tested it (to a certain point) and then had the very stressful and uncertain releases. Sometimes it ended in chaos and we had to revert the release but most of the times it worked, somehow.
One could argue if that was really continuously. But what does “continuous” actually mean? It’s etymological definition seems to be ” uninterrupted, hanging together”. Does that mean that a software releases once or twice a year, or 3 years in a row is a continuous delivery, too? Or something released on every defined deadline? Maybe.
Delivery Pipeline? An utopian dream!?
People first being introduced to the concept of a Delivery Pipeline in CD often think this is a too idealistic idea and won’t work with their projects.
But even something like that we had for ages. The difference is that almost all of our steps were manual, fractured and siloed instead of having e.g. automatic pushing to pre-production or live stages. When releasing the 65th time the same boring and tricky way not everybody started to ask himself why those repetitive steps aren’t automatable.
Software and most systems are automatable. And the base of our own software are libraries, frameworks, platforms or operating systems – in other words software. So it should be automatable, too. Most of us are already doing this to a decent part, what else are build tools and scripts for?
What’s the hype about then?
So what’s the difference between (ancient) releasing/delivering software and the “new” methodology, known as (agile) Continuous Delivery, that the last years arose?
The interval of delivery or the reason for delivering doesn’t seem to be it.
Therefore it may be the grade of confidence in your process of doing it so. In other words the grade of elimination of error-prone, dangerous, time-consuming or tricky steps. And the understanding that software has to be designed in that way that changes to it should be easy doable and shall not be the reason for work-loaded and stressful weekends and sleepless nights.
In essence: the grade of automation of manual or often repeating but complicated steps, the sensible dealing with mission-critical scenarios when they may go wrong and what to do then, and the increasing of speed and frequency to do this all.
The paradigm has changed
In contrast to the “ancient times”, when software was often one piece of a monolithic structure that could be released only as a whole, today we think in smaller components and easier changeable software.
That can still be still monoliths (but based on a better architecture, i.e. low coupling) but in most cases every single component can be changed and deployed separately – not influencing the operation of others. Plugins, widgets, apps, pipes & filters, unix commands – it’s all here, already.
And you can adapt your CD or CD pipeline to every component differently.
As with other parts of a clean architecture – even deployment and delivery should be just an implementation detail.
Every idea has its time
Though not a brand new concept at all, CD’s time (in its current form) has definitely come today, at least.
Maybe a few years ago all of this was too hard to achieve, at least up to current degree. But with today’s possibilities, e.g. virtualization, automatic testing tools or clouds, that isn’t really hard anymore. Nowadays we can deploy a new version of our software even on infrastructure we don’t even know of where it is, why then we can’t on our own systems?
There are no excuses to do repetitive, error-prone and inconsistent manual work in highly automatable and independently changeable systems anymore.