Businesses want to stay competitive, but in today’s world of software development it can be a struggle. In order to be successful, businesses need to deliver software that loads quickly, performs well, and provides a great user experience, and they have to do it fast.

It is no longer acceptable for a business to deliver software and updates annually, or for organizations to wait until the end of a development cycle to test an application, according to Nikhil Kaul, technical product manager at SmartBear. The way in which software is delivered is being sped up and compressed, and businesses not only need to find a way to keep up, but also release high-quality software at the same time.

Continuous Delivery (CD) is an approach businesses have taken to release software more frequently, bring products and services to market, and ensure quality.

“CD is how companies recognize that software is eating the world, and that they won’t be able to remain competitive if they don’t radically change the way they produce business differentiation through software,” said Sacha Labourey, CEO and founder of CloudBees.

Of course, with any methodology that speeds up the delivery life cycle, there is a risk of releasing low-quality software. But with a process like CD, the quality of software actually improves if implemented the right way, according to Eric Wittman, general manager of developer tools at Atlassian.

“Part of the biggest benefit is you are able to get immediate and instant feedback on whether or not your software actually works. In its simplest form, that is the biggest benefit,” he said.

That immediate feedback comes from breaking down barriers between the business, development, quality and operations teams, getting feedback on a much faster cycle, constantly testing an application as the code is being written, and working in smaller batch sizes, according to Dave West, chief product officer at Tasktop.

“Remember, if we are doing Continuous Delivery, it is likely we are working in small batch sizes, and if there is a bug, it is less of a massive ‘Whoa, the world has come to an end’ situation,” he said. “You are able to fix it relatively quickly, and you get the ability to deploy again relatively quickly. It is all about visibility. As soon as you see the problem, you try to fix it. And if you miss problems, then you add layers of automation to fix those problems next time.”

SUBHED: Prerequisites to doing Continuous Delivery
Before an organization can even begin to head down the path to Continuous Delivery, it needs to ask itself why it wants to implement it, according to Andrew Phillips, vice president of product management at XebiaLabs.

“The one thing I always start out with is ‘So, why are you doing this?’ If they say they want to do Continuous Delivery because it is Continuous Delivery, then that is not an answer,” he said. “You have to have some kind of business motivation for doing this. If you can’t give me some reasonable measurable goal that you want to achieve as a business, then how on earth will you know if you are going in the right direction?”

Although the rewards for a Continuous Delivery approach are quite desirable, it isn’t necessarily a good fit for all. And if an organization doesn’t know why they are doing it, they probably shouldn’t be doing it in the first place, according to Phillips.

“You have to have a need to do it. Don’t jump on the bandwagon just because the bandwagon happens to be rolling past your door,” he said.

Once an organization figures out its business goals, it needs to understand the current state and the desired end state of its business in order to decide on the best course of action.

“If you don’t understand both, then you are in danger of making the wrong decisions about how to adjust your people, processes and technology to achieve CD,” said Anders Wallgren, CTO of Electric Cloud.

Since the idea of Continuous Delivery relies on the idea that software should always be ready to ship, organizations should be able to respond quickly. To do that, development teams should be focused on working in smaller increments and at an agile pace, according to Michael Butt, APM product specialist at AppDynamics.

“Continuous Delivery is based on the idea that a new version of software should be able to be deployed in production at any point in time and not be limited by calendar-based deployment schedules,” he said. “Agility is required to be successful in today’s business environment, and CD is a core enabler when rapid execution is needed.”

And as it is with the agile methodology, teams should have a culture of collaboration in practice. Everyone who is involved in the end-to-end process such as developers, testers, QA, operations and management should be on the same page, according to Phillips.

“They need to know not just what has to happen to get the piece of code from the developers’ IDE into the repository, but what it takes to get this process all the way into production,” he said. “Then you have to have the openness to say the way we are doing it now probably isn’t the best way; let’s all get together and figure out how to make this process better.”

In addition, development teams should already have a Continuous Integration approach in order to achieve Continuous Delivery. (Continuous Integration, the process of merging code into a shared repository throughout the day, precedes Continuous Delivery.)

“What happened over a decade ago was that every company delivering software realized they needed source code management; you couldn’t have source code sitting in developers notepads effectively,” said Mik Kersten, CEO and cofounder of Tasktop. “That triggered these companies’ tooling off the way that they build software, and that triggered the fact that they needed to get build off developers, which triggered the whole Continuous Integration movement.”

Getting over the Continuous Delivery obstacles
Implementing any strategy comes with its difficulties, and it is especially difficult with Continuous Delivery because unlike methodologies like agile, there are no official guidelines to applying it to the organization, according to XebiaLabs’ Phillips.

“Continuous Delivery doesn’t have an obvious implementation plan,” he said. “It is still stuck at the stage where it is a great idea. I mean, how can you say no to faster, better, cheaper? But nobody really knows how to do it, and the only examples you can look at don’t translate very well to the kinds of organizations that are looking at it right now.

“It is a little frustrating because it means there is interest, but there is a significant bottleneck in terms of people actually knowing how to adopt it.”

There many not be any manifesto yet, but many organizations have already turned to Continuous Delivery, and their successes and failures can be a lesson to Continuous Delivery organizations to come.

“The first thing teams should do is see how other people are doing it,” said Atlassian’s Wittman. “What works for them based upon the types of software that they are building.”

While a Continuous Delivery process often involves other methodologies such as agile, continuous integration and continuous deployment, these processes are all still working toward the same goal and should not be viewed as siloed processes, according to Electric Cloud’s Wallgren.

“The Continuous Delivery challenge needs to be viewed as one continuous process, not a set of different processes,” he said. “Not having a single end-to-end process introduces delays and errors.”

Recognize what your delivery needs are and understand the level of quality and risk that is acceptable to your organization,” said AppDynamics’ Butt.

“There is no one-size-fits-all rate of delivery. Some organizations might release several times in one day, some several times a week or even every month. The important thing to focus on is the ability to release incrementally with as much automation as possible, enabling agility,” he said.

Don’t let the tool get in the way. If it isn’t working, you are probably using the wrong tool, according to Wallgren.

“Technology obstacles refer to any system or technology that prevents the ability to create one end-to-end system that shepherds your code from check-in to delivery to avoid gaps in the automation,” he said.

Tools, technology and process may get in the way of Continuous Delivery, but one of the biggest obstacles is people, according CloudBees’ Labourey.

“Moving from a siloed organization to cross-cutting teams requires quite a bit of brain rewiring,” he said. “Some individuals might feel challenged in their habits and/or authority. But as General Eric Shinseki once said, ‘If you don’t like change, you’re going to like irrelevance even less.’ ”

Strong support from management can help organizations overcome these obstacles, but a clear understanding on why this is happening is also important, according to Atlassian’s Wittman.

“The team has to buy into this as a value. They need to see that this is something that is valuable to them and how it can help them build better software,” he said.

Although Continuous Delivery is a way in which teams need to work, it is a culture and a mindset as well.

“Lots of people tend to focus too quickly on the technical aspects of CD, on how to get there, but don’t take time to fully grasp the significance of this profound revolution that both IT and businesses are going through,” said Labourey.

Always remember that the road to Continuous Delivery is bumpy. Organizations need to remain patient and open in order to reach their destination.

“This sounds trite, but is very important to keep in mind: You won’t get there overnight, and if you try to do it that way, you’ll fail,” said Wallgren.

Bringing agile to the next level
Agile has a lot of the same benefits as Continuous Delivery, but shouldn’t be confused with being a CD strategy, according to Labourey.

“This can indeed be confusing as the Continuous Delivery philosophy shares a lot of things with the agile methodology, and agile is very frequently used as the methodology of a Continuous Delivery strategy,” he said. “CD defines how a business is able to continuously deliver value, how a feedback loop is built to include the business. Agile defines how that value gets built. But ultimately you can be agile without doing CD, and vice versa, even though they are a great fit.”

In agile, the focus is on getting the teams to work better together in order to deliver software, and the focus in a Continuous Delivery strategy is on actually delivering the software, according to Tasktop’s West.

“The two are incredibly linked,” he said. He believed that though an organization doesn’t have to be agile in order to practice Continuous Delivery, he doesn’t know why it would want to.

“Can you do Continuous Delivery for a waterfall life cycle or a more traditional life cycle? Yeah, but why would you want to? There are no real benefits,” said West. “Of course you could employ some of the technology being used for Continuous Delivery in the life cycle, but your backside is still very large and your release cycle is annual. The benefit of employing the technology is simply reduced.”

Typically, an organization should already have some sort of agile methodology in place before it moves onto implementing Continuous Delivery, according to Atlassian’s Huselid.

“If you haven’t embraced agile already, you are probably not ready for it,” she said. “If you are not developing software in a way where you are delivering small, bite-size chunks of code over shorter periods of time, you will fall down on Continuous Delivery. Continuous Delivery is taking agile to that next step, which is not just I am building in that way, but I am delivering in that way.”

Tools are key, but not the key to Continuous Delivery
According to XebiaLabs’ Phillips, organizations typically think of Continuous Delivery as a blueprint of tools they need to implement, but the truth is tools are a way to improve the way an organization works. Tools are not a what, but a how.

While it isn’t just a blueprint of tools, a team of developers alone cannot speed up the release time of software; tools are a crucial part to implementing a Continuous Delivery strategy, according to the results of Evans Data Corp.’s North American Development Survey, 2014, Volume II. The report revealed that developers rely on source-code version-control and bug-tracking tools to successfully execute CD strategies.

“This shows the importance of tools in automating the Continuous Delivery model,” said Janel Garvin, CEO of Evans Data. “Without tools to enforce processes and enable developers to rapidly release and deploy new versions, Continuous Delivery is just a set of best practices.”

With tools being an important part of the strategy, organizations need to make sure they choose a tool that serves as the backbone of their automation efforts, according to Electric Cloud’s Wallgren.

“Using many different tools will increase your need to integrate them, which introduces delays and opportunities for mistakes. This then allows you to choose best-of-breed or fit-for-purpose tools for individual parts of your process and have your automation platform drive those tools,” he said.

Although Wallgren suggested it is better for an organization to pick one tool, CloudBees’ Labourey said that most companies adopting a CD approach will already have a lot of IT assets in place and will have to automate a pipeline that will mix a lot of existing tools. So, when looking for a tool that will be the most effective for your organization’s delivery strategy, the product should be flexible.

“Probably one of the most important aspects of the tool you’ll be using to build your overarching CD pipeline lies in its ability to plug in an extremely wide variety of tools and makes it trivial to implement your own custom integrations, in an open fashion,” he said.

In addition, the tools an organization decides on should be able to cover the builds, run the tests and orchestrate deployments, according to Atlassian’s Wittman. Also, they should provide some sort of metrics so that organizations can tell they are going in the right direction, according to XebiaLabs’ Phillips.

Last but not least, when choosing a tool, organizations should remember that while the tool can help ease the process for development teams, only the team can achieve success, not the tool, according to SmartBear’s Kaul.

“It requires a commitment, and if that commitment is not there right from people and the organizations, you can provide the tools to the people,” he said. “But at the end of the day, if you do not have people willing to work on the tools, the tool is not going to deliver the results on its own.”

Best practices to successfully implementing a Continuous Delivery strategy

  • Continuous Integration: “The first, most fundamental thing you need is you need to be doing Continuous Integration,” said Tasktop’s West. “If you haven’t adopted a good source-code-management approach, a good build approach, then you are not automating certain aspects of your testing life cycle, and there is no way for an organization to start to implement Continuous Delivery.”
  • Start small and experiment: “Set up an experiment site where you can make a lot of these changes and try to identify what works for your company,” said XebiaLabs’ Phillips.
  • Automate, automate, automate: “Automate everything. There should be no manual intervention needed in order to take your software from developer check-in to delivery readiness,” said Electric Cloud’s Wallgren.
  • Teams must be transverse: “You won’t succeed with your CD strategy if you keep an ‘us vs. them’ philosophy,” said CloudBees’ Labourey. “Project teams are composed from all stakeholders of the value creation. This is a radical shift away from how companies are typically structured, vertically, in silos.”
  • Don’t remove business from the CD equation: “A CD strategy is not [a strategy] if it doesn’t embed business,” said Labourey. “A feedback loop from IT within IT is an internal IT strategy, not a CD strategy.”
  • Focus on incremental releases and be flexible with what gets delivered: “Forcing features and functionality is counter to the agility you’ll gain by employing CD,” said AppDynamics’ Butt.
  • Have the right tools in place: “Have the right tools in place to ensure you can not only automate yourself, but also ensure you can reuse your stuff from development to even testing to even when you are doing your operations,” said SmartBear’s Kaul.
  • QA has to be much more involved in the process: “When you implement the QA team before the code is being written, it means that you would be spending less time testing later on because you can clear unambiguous requirements, and at the same time you can ensure that your costly development mistakes are avoided,” said Kaul.
  • Implement traceability into every step along the way: “Every time you are building something, whatever a build contains—whether it was a new feature [or] a bug fix—you have to have some sort of tracking between what you were fixing and what to get fixed and where it got shipped to,” said Alison Huselid, head of product marketing for developer tools at Atlassian.