In an IT universe that contains some companies still working on annual software releases, frequent software updates can be a competitive advantage. No discipline supports software updates on a more rapid schedule than continuous delivery.
The question for most organizations is how to get from agile -- or even waterfall -- to continuous delivery. The answer comes in meaningful steps.
Continuous delivery is defined by some as a process in which code can be released to production at any time. Others define it as a system in which software is constantly revised, with revisions pushed out to production as soon as they're available.
How often can those revisions occur? There are cloud service providers that talk of releasing scores of revisions a day.
Continuous delivery is part of a "continuous" hierarchy. The steps on the hierarchy are:
- Continuous integration: Code is written, integrated, and tested within the development environment. Walls between the three functions are broken down to make one smooth, continuous process.
- Continuous delivery: Software and component revisions are made ready for deployment on a continuous basis. The organizations might choose to hold those revisions for scheduled releases, but the gating factor is the schedule, not revision availability.
- Continuous deployment: Every revision is deployed as soon as it's delivered. The code pipeline never shuts down, because automation processes take care of all the deployment steps.
Continuous deployment is an important trend in enterprise IT. According to IDC, by 2018 more than 60% of enterprise apps will use cloud-enabled continuous deployment as their delivery mechanism. This means that companies not using continuous deployment could easily find themselves at a competitive disadvantage compared to those pushing updates out the door on a moment-by-moment basis.
Not every organization is ready for continuous deployment. While agile methodologies and DevOps can lay the foundation for continuous deployment, there are significant organizational, cultural, and technological changes that have to occur before the code pipeline can be opened for users.
After looking at resources on the web and talking to many different IT managers and executives, I find that six steps stand out as critical for any organization that wants to get to continuous deployment.
It's important to note that these aren't the only six steps on the path. You might think of them as landings on a staircase, or scenic overlooks on a longer trail. No matter which visual metaphor helps you, do realize that these are not optional. They are steps that every organization must take on the way to continuous deployment.
If your organization has already made the move, I'd love your take on the steps in this list. Are there others you see as critical? Do you think that one of these is oversold? Let me know -- the comments are open on a continuous basis.