How cloud drives Continuous Delivery
Once upon a time we received new software 'builds' every year. For major releases at least, this annual cycle was the standard (or 6-month cycles at the most) and software firms would usually name the new iteration after the year it had appeared.
Somewhere around the turn of the millennium this annual trend started to erode.
New forces, faster cadence
A faster tempo for software occurred partly due to the arrival of the Internet and partly due to other factors including the growth of mobile, the speed of information inside social collaborative platforms and ultimately the popularisation of the cloud model.
Suddenly users wanted updates far more frequently than once per year and if they couldn't get them they would look elsewhere at different applications, cloud services or data channels.
These factors have driven us to coin the term Continuous Delivery (CD) - a software discipline where we build software in such a way that the code can be released to production at almost any time. Continuous Delivery is inherently well suited to cloud-centric models because cloud applications are 'always on' and need to be updated on the fly.
Continuous Delivery theoretically makes it possible to constantly adapt software in response to user feedback, market shifts and changes to business strategy -- at any time.
Inside the continuous model we see that testing, support, development and operations teams work together as one single unit to automate and streamline the build, test and release process.
The Facebook example...
It is often said that Facebook updates (or 'delivers') as many as 14 times a day to bring new features online. But we as users never know that continuous improvements or augmentation that is happening and serving our user interfaces.
Whether Facebook delivers 4, 14 or 40 times a day, the point still stands - cloud & web based applications and services are able to deliver small changes and even platform-level upgrades while users remain relatively oblivious to these enhancements.
Alongside Continuous Delivery we will also want to utilise Continuous Integration (CI) and show a wider understanding of software application lifecycle management to the systems we build. But to really achieve the continuous dream we will also require a degree of dedicated management software.
How do we "do" continuous?
Cloud management software with automation intelligence is typically used to bring the continuous factor into any software development environment and then to provision, manage and deploy applications across private, hybrid and public clouds continuously.
In order to carry forward continuously we will need to reject any one size fits all approaches and be ready for dynamic scaling of the services we aim to deliver (both upwards and downwards). But scaling and flexibility are what cloud is best at anyway, which is why we are having this discussion in the first place.
Taking stock then...we can see that Continuous Integration is the practice, methodology and process of testing each piece of software code every time it is 'committed' by a developer and programmer or even a semi-technical business user these days. Above this we place Continuous Delivery to package software and apply layers such as regression testing to it so that we can ensure it is ready for release.
Cloud has cadence, cloud has connection and cloud has connectivity. Because of this cloud needs continuous tooling to make its software work. Continuous connected continuity is a fundamental part of the cadence of cloud, so get used to it.