5 things you need to know about Continuous Delivery software development

By Andrew Phillips, VP of product management, XebiaLabs, Network World |  Software

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

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.


Originally published on Network World |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness