1. What are the benefits to implementing a continuous delivery strategy?
The key benefit to implementing a CD strategy is to bring IT closer to the business, much closer. IT is still, by and large, seen as a remote executing arm of the business. Business requirements are “shipped” to IT which interprets and implements them, later delivering its output back to the business. This is a totally inefficient way to do things. Software is everything today: this is how we interact with customers, partners, vendors and most of a company’s differentiation happens. Continuous delivery makes sure business value is translated into software in a continuous fashion, by including all stakeholders, from business to IT Ops through development, QA, etc. Continuous delivery is the realization that Business is IT.
2. What are some principles teams need to follow in order to achieve a successful implementation?
First of all, teams must be transverse: you won’t succeed with your CD strategy if you keep an “us vs. them” philosophy. 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. Then, value creation must be able to happen in quick iterations, as small as a day in some cases. This implies that the pipeline used to go from source code changes to actual bits running in production must be fully automated: you will only be able to have fast iterations if the marginal cost of an iteration is close to zero. Then, you need to be able to measure whether what you are delivering is actually delivering the value you were expecting. Last but not least, never ever remove BUSINESS from the CD equation: a CD strategy is not one if it doesn’t embed business. A feedback loop “from IT within IT” is a business-autistic strategy, not a CD strategy.
3. What are some obstacles organizations can expect when implementing those principles?
Technically, moving to a fully automated environment, where an automated “pipeline” can essentially carry your IT assets from code to production, takes time to get right. You’ll find lots of great tools and best practices, but your company will essentially have to define its own way, which will take time and smart engineering. But interestingly enough, the biggest obstacle is typically not technical, but rather “political.” Moving from a siloed organization to cross-cutting teams requires quite a bit of “brain re-wiring.” 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.”
4. How does continuous delivery differ from the agile methodology?
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. 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 imagine to be agile without doing CD and vice versa - even though they are a great fit.
5. How do you choose the tooling that will be most effective for your delivery strategy?
Most companies adopting a CD strategy already have lots of IT assets in place and won’t have a “clean slate.” Consequently, they’ll have to automate a pipeline that will mix lots of existing tools: build tools, test tools, deployment tools, databases, etc. Consequently, probably one of the most important aspects of the tool you’ll be using to build your over-arching 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. This is probably the key reason why Jenkins is so popular for CI and CD in thousands of organizations around the world.
6. How can testing keep up to the speed in which software is being delivered?
This is definitely a big challenge and an era in which lots of innovation is happening. Companies will typically create a cascade of testing, putting first any testing that is “cheap,” both time-wise and resource-wise, and increasingly adding sophistication, to eventually end-up with the most costly (time- and money-wise): manual testing. Some testing vendors can offer some pretty sophisticated tools that make it possible to extract, as much as possible, the delta between two releases and only test those differences.
7. What is important to note about continuous delivery? What should organizations be focused on?
The most important is probably to realize that CD is not a tool, not a product, not a vision. It is not even a choice. 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. 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.
CEO and Founder
Follow Sacha on Twitter