Continuous delivery is a software strategy that seeks to provide new features to users as fast and efficiently as possible. The core idea is to create a repeatable, reliable and incrementally improving process for taking software from concept to customer. Think Agile principles. And, think frequent, reliable execution of repetitive tasks ... i.e. think automation.
Like DevOps, Agile and similar recent initiatives, continuous delivery is fundamentally a set of practices and attitudes. Continuous delivery isn't "solved" by putting a smart magic box, suite or toolset in a corner; it is implemented by committing to adopt a mindset and working towards a set of goals derived from those principles.
For most organizations, though, the goals of continuous delivery require error-prone, expensive and time-consuming manual processes.
That being said, organizations cannot afford to risk significant disruption to a business-critical process such as application delivery through "big bang" automation approaches that attempt to move the entire process to supposed "one-stop-shop" suites in one go.
Instead, companies should adopt a phased approach to implementing continuous delivery, making smooth transitions that deliver measurable improvement.
Here are five considerations for continuous delivery:
* It lowers your costs. Traditional software deployments require mostly manual work such as expert scripting and frequent troubleshooting sessions, all of which add up to a significant investment. As long as the amount of deployments progresses, the amount of expenditure grows. Due to rising cost (and deployment duration), the maximum amount of deployments per hour is also bound to limits.
In a continuous delivery environment, the number of deployments does not have a large impact on overall costs. Once a deployment pipeline is configured, subsequent deployments happen automatically or at the push of a button. The maximum amount of deployments is not limited to error-prone, manual tasks.
* It shortens your time to market. In the traditional process, many changes are delivered in one big release. The time between releases is long and much effort is required to deploy the software. A big release with many changes almost inevitably gets delayed because you can't get many features to work together in one go.Furthermore, a manual release process is quite inefficient. For example, if three changes fail the test in a release containing 100 changes, the 97 correct changes cannot go into production until the three defective ones are fixed.
In a continuous delivery model, small batches of changes are moved continuously and become instantly visible. Changes can be made immediately available to customers — and customer feedback can be gathered within minutes. When a feature is ready for production, it can be moved there without delay. This kind of quick feedback makes it easier to ensure the next thing you build is aligned with your customer expectations. Such speed is vital as a new feature can mean instant business value.
Sign up for Computerworld eNewsletters.