Continuous Delivery (CD) is often thought to be within the purview of tech practitioners - developers, testers, operations, delivery managers, etc. However, the industry is fast realizing that CD is actually more of a business decision. CD can be the game changer to help the organization stay a step ahead by delivering value to the customer reliably and frequently. CD isn’t a geeky fad, but a huge business enabler vouched for by Facebook, LinkedIn, Flickr and the like. So how does the executive put their finger on CD? What is the groundwork required for an organization to be CD-ready? Isn’t it enough to just do Continuous Integration (CI)? Do managers now have to hire specifically for the role of “Devops”?
To answer this and more, we chat with Luca Minduel and Kief Morris. Luca has been working in professional software delivery since 1989, and now coaches top-tier organizations in Europe and the United States in implementing Lean and Agile best practices for ThoughtWorks. Kief is ThoughtWorks' Europe Practice Lead for Continuous Delivery. He enjoys helping ThoughtWorks clients to harness disruptive ideas in software delivery and operations, such as DevOps, Lean, and cloud platforms.
1. Why should the executive bother with CD? What is the key benefit from their viewpoint?
Luca: CD supports innovation and products development, it helps to quickly explore the market and the reaction of users to new ideas and new technologies. CD can increase organization’s responsiveness: it reduces the time required to build and release new features, to change direction and react to new circumstances. CD also overcomes the infamous ‘90% done’ syndrome because it makes real project progress always obvious and tangible. And finally CD increases the stability of production systems and turns risky painful releases to production into predictable, safe and regular events.
Kief: IT is often an inhibitor to innovation in business. Great business ideas are held back or completely stopped because of the expense, time, and disruption that would be caused by the changes to IT systems needed to make them happen. CD looks to change software delivery processes to emphasize delivering small changes safely and quickly. Big ideas can be built up in this way over time, with a continuous stream of feedback and real-world data to ensure the right solution is built.
2. How does an executive assess where their organization stands in its CD journey?
Luca: Every organization is different and unique. So I like to start understanding what the value proposition of CD for that organization is. Then there are two questions that help to give a general sense of where the organization currently stands: One - how often do you release to production? Two - how much time it takes for an urgent bug-fix, for a change request and for a new product to go from concept to cash, from the idea into the hands of your users? The current trend in the IT industry is to reduce the time required for each new release from years and months to weeks, days and hours.
3. What are the top 3 changes required to prep an organization before they embark on implementing CD?
Luca: Iterative Development, Continuous Integration and Test Automation are all prerequisites of CD. It’s quite common that a CD journey includes improvements in all those 3 areas.
4. Isn’t CD way too disruptive for my organization’s team structure? How does an executive change the work culture?
Luca: With regard to the team structure, I see CD as a tool that highlights the needs of an organization and helps to find out which team structure can better support them. The team structure indeed depends the ability of an organization to find out good solutions to complex problems and to work efficiently. An organization can support the evolution of the team structure by creating an environment where everyone’s focus is on the entire value-stream - from coding to release, from concept to cash. An organization can create an environment that encourages the collaboration between departments and functions with the common goal of creating business value. People on teams should be involved in identifying the bottlenecks and in shaping improvements.
5. How does CD impact hiring? Do companies need to hire specifically for DevOps?
Kief: Adding a new role or, worse, a new team, misses the point of DevOps, which is to break down barriers and get people to share ownership of the end-to-end process of conceiving and delivering software. Rather, it would be more helpful to ensure that new people hired into the organization have a genuine enthusiasm for getting involved in various aspects of the delivery process.
6. In your experience putting CD into practice organization-wide, what have been the biggest challenges executives have faced? How have they dealt with them?
Luca: There are internal and external factors that can make it more difficult to adopt and apply Continuous Delivery. For instance - lack of training, high levels of confidentiality that prevent cooperation and information sharing, disincentives for experimentation and fear of failure, compliance to external regulations and policies. More often than not these obstacles can be removed. For example, problems with external policies are often due to implementations of an interpretation of a policy, while there are lightweight ways to achieve the policy goals that actually produce better outcomes.
Useful elements to deal with the biggest challenges of CD are: involvement and a shared commitment of the people affected by the CD implementation, transparency and visibility, together with skills and experience with CD.
7. What are the “minimal” technical practices to put into place to get the most out of CD?
Luca: I would start with Iterative Development, Continuous Integration, Trunk-based Development, developers and testers working together on test automation and developers and IT Ops working together on automatic deployments.
8. The market for CD tools is mushrooming. Any advice on picking the right ones?
Luca: A successful product will grow over time and so will the related code-base. The implementation of CD will thus have to evolve too. In order to support this growth easily, a CD tool should implement the pipeline concept as a native first-class concept. It should be cross-platform compatible to support a large variety of technologies. And it should be able to distribute the build tasks across many computers, as in a build-grid, to support increased workload. It should support scripting to enable refactoring and support VCS. And finally it should follow a clear separation of concerns to enable a proper integration of different tools and to allow easy replacement of tools over time when needed.
9. We’ve put in CI and CD into practice. What is this new “CD” - Continuous Deployment? What is the value in it?
Luca: In Continuous Deployment every single change that leads to a release candidate version of the software is also automatically deployed to production. You can do Continuous Deployment when you trust the CD pipeline, your test automation, your CD process, and the deploy is so smooth that users don’t even notice it except for having access to the new features. With Continuous Deployment, every release is smaller so the risk is smaller. Every feature goes into production earlier and thus starts to generate feedback and business value earlier.
For a comprehensive and concise overview of CD download Luca and Kief’s “Continuous Delivery Overview”