Continuous Delivery is all the rage for dev teams and the release management / application delivery marketplace. And rightfully so, as it is the application delivery methodology that lets App Dev deliver the code. It saves time and money as it cuts the time for applications to be delivered into production.
A key driver for Continuous Delivery has been the adoption of Agile as a development methodology. Most of our long-term application lifecycle management (ALM) customers have implemented at least some agile development processes, and Continuous Delivery is next up for them.
At Agile 2012 last year, we surveyed the audience and found that 49% of the respondents’ companies have significantly adopted the use of Agile for development. And 55% of those respondents said that they are “already there” or “getting there” in the use of Continuous Delivery. Take a look at the infographic from the Agile 2012 conference and survey. Note also that we’ll be at Agile 2013 in August and we’ll rerun the survey and provide our annual Agile Conference Survey report for you! We’ll see what the adoption rate for Continuous Delivery is after another year.
While Continuous Delivery does provide great value, it is not appropriate for all application deployments. Many applications require a separation of duties: App Dev develops and IT Ops deploys. Hence, deployments into production follow the traditional stage gate methodology and are handled by IT Operations. This hybrid of Continuous Delivery and Stage Gate Delivery is Continuous Deployment; it can be implemented with Release Automation plus release process control and management of the hand-offs between App Dev and IT Ops.
To learn how you can implement Continuous Delivery as quickly as possible while still supporting the traditional stage gate delivery process, watch our recent webcast “Implement Continuous Delivery with Traditional App Dev Processes“ featuring Julian Fish, Director of Development for Serena Release Manager.
|Ashley Owen is the Director of Orchestrated ALM Strategy at Serena Software. Ash has worked at Serena Software for more than 20 years and is passionate about solving application delivery problems spanning demand, development, and deployment.|
Thanks for posting this, Ash. I did, however, find it a bit misleading. First, participants at an Agile conference will be skewed toward embracing approaches such as Continuous Delivery. Second, I find it very unlikely that a relatively large % people are doing Continuous Delivery (if I understand your graphic and description it’s around 30% of 55% of 49%?). This is because people don’t even know what Continuous Delivery truly is. A better question to ask respondents is whether they’re *releasing* software products/systems to *production* once per every two-week iteration – or more frequently. The answer to that question cuts through a lot of ambiguity and misunderstanding of definitions. This is also why I think there’s little value in the “How Agile Are You?” questions. Both indicate an insular focus within the IT community that seems to disregard the customer/users. There’s a problem with my question as well because Continuous Delivery doesn’t suggest how often you release to production, but, at least, it gets through the potential definition misunderstanding.
Also, I found your description of Continuous Deployment confusing. Continuous Deployment means that the software product/system gets automatically deployed to production immediately after it passes all of the delivery pipeline steps (consisting of things like build, environment provisioning, deployment, testing, static analysis, etc.). Continuous *Delivery* means it’s a business decision to deploy to production; with Continuous Deployment, it just happens with every *good* change. This graphic depicts what I just wrote fairly well: http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment
Thanks Paul, much appreciate your commentary, I certainly don’t mean to be misleading and acknowledge these terms are often used interchangeably. The results do provide an interesting data point, and in the context of agile development I am mindful we are not really done until it is working in production.