What emotions does the word “release” trigger in you?
If your team is still living with manual testing to prepare for releases and manual or semi-scripted deploys to perform them, your feelings may be closer to
That’s why software development is moving towards continuity.
The recent emphasis on continuous integration, built-in testing, constant monitoring, and analytics feedback all point toward an overall trend in the software industry: increasing the ability to react. As organizations explore what these changes mean for them, they invariably discover continuous delivery, commonly known as CD.
Make no mistake: CD is not the exclusive domain of “unicorn” companies. Every team – from the humblest start-up to the big enterprise – can and should practice Continuous Delivery.
This blog takes a look at the business case for making this switch. It will discuss the work that lies ahead and the benefits it will yield.
What is Continuous Delivery?
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 completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.
Why continuous delivery?
It is often assumed that if we want to deploy software more frequently, we must accept lower levels of stability and reliability in our systems.
The practices at the heart of continuous delivery help us achieve several important benefits:
- Low risk releases – The primary goal of continuous delivery is to make software deployments painless, low-risk events that can be performed at any time, on demand.
- Higher quality – When developers have automated tools that discover regressions within minutes, teams are freed to focus their effort on user research and higher level testing activities such as exploratory testing, usability testing, and performance and security testing. By building a deployment pipeline, these activities can be performed continuously throughout the delivery process; ensuring quality is built in to products and services from the beginning.
- Lower costs – Any successful software product or service will evolve significantly over the course of its lifetime. By investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process.
- Better products – Continuous Delivery makes it economic to work in small batches. This means we can get feedback from users throughout the delivery lifecycle based on working software. Techniques such as A/B testing enable us to take a hypothesis-driven approach to product development whereby we can test ideas with users before building out whole features.
- Happier teams – Continuous Delivery make releases less painful and reduce team burnout. Furthermore, when we release more frequently, software delivery teams can engage more actively with users, learning which ideas work and which don’t, and seeing first-hand the outcomes of the work they have done. By removing the low-value painful activities associated with software delivery, we can focus on what we care about most—continuously delighting our users.You’re doing continuous delivery when:
- Your software is deployable throughout its lifecycle
- Your team prioritizes keeping the software deployable over working on new features
- Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
- You can perform push-button deployments of any version of the software to any environment on demand
To achieve continuous delivery you need:
- A close, collaborative working relationship between everyone involved in delivery (often referred to as a DevOpsCulture)
- Extensive Automation of all possible parts of the delivery process, usually using a DeploymentPipelineContinuous Delivery is sometimes confused with Continuous Deployment.
What’s the difference?
The principal benefits of Continuous Delivery are:
- Reduced Deployment Risk: Since we are deploying smaller changes, there’s less to go wrong and it’s easier to fix.
- Believable Progress: Many folks track progress by tracking work done. If “done” means “developers declare it to be done” that’s much less believable than if it’s deployed into a production (or production-like) environment.
- User Feedback: The biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is.
Continuous Delivery requires change from teams across the organization. It requires focused investment in tooling, hardware, and people. All of that takes time. And all of it is possible.
This Blog was a quick Introduction to Continuous Delivery. In coming Blog I will write on variety of feedback loops-both manual and automated which organization should have in place before rolling out CD. So help me write better blogs by giving your valuable feedback.