Accelerating Continuous Delivery: Best Practices for On-Prem and Cloud

As demand escalates for business apps, more and more companies are looking to go beyond CI (continuous integration) – and achieve impactful Continuous Delivery. Here’s a roadmap to take your CD efforts to the next level, thanks to execs from CloudBees, a platform as a service provider specializing in CD.

Tags: ALM, AWS, Azure, CD, Chef, cloud, CI, CloudBees, deployment, Docker, Jenkins, test, Puppet,

Sacha Labourey

"The process of moving from CI to CD is a logical but sometimes daunting process."

Integration & Web APIs
Enterprise-Grade Integration Across Cloud and On-Premise
June 23
Online Conference

By definition, continuous delivery is not a “project” with a defined conclusion. It’s a “process” that stakeholders need to cultivate, improve and drive forward – even after that process seems to be working just fine.


So, the question begs: What initiatives should you undertake when you feel like your continuous delivery (CD) pipeline is running well? How do you take your CD operation to the next level?


Looking at a number of successful CD implementations and listening to some of the world’s top thought leaders on the matter, I’ve come up with a few best practices that can keep the improvements coming.


Starting out: from CI to CD
CD grew out of continuous integration (CI), which is the practice of automatically building and validating each change immediately, identifying errors early and fixing them faster.  The process of moving from CI to CD is a logical but sometimes daunting process. It means automating more, involving more people, and extending beyond the comfort of the development domain to consider quality assurance, operations and other steps of the software delivery pipeline.  


You may be asking: “It was tough enough to get the development team on board. How do I influence change across all of these teams? Don’t worry!  It can be done -- and is well worth the effort.


As found in the survey “Continuous Delivery: The New Normal for Software Development” by Evans Research and Perforce, 65% of organizations are practicing CD on one or more projects with the top two benefits cited as “Faster time-to-market” and “Better quality products.”


To make the transition, you will need to involve downstream stakeholders, build excitement, invest in new skill sets and be pragmatic not dogmatic, adjusting plans to address challenges as they are encountered. Usually, it starts with establishing automation of the delivery pieces with a cross-functional automation engine and addressing cultural and process needs along the way.  In short, “Push” and push right.


Push farther to the right along your continuous automation pipeline
This is a fancy way of saying, “Get more aggressive.”


If a typical pipeline moves left to right, from source code on the left to production on the right, procedures call for teams to start automating facets early in the process and then tackle those closer to production later. It’s usually an issue of resources: You can’t pay for everything all at once, so win the battles you can win. When you feel you can generate a return on investment, push deeper into your pipeline and get into more territories.


For instance, moving CD close to production is more of a challenge because tooling in a production system isn’t truly automated. Leveraging configuration management solutions such as Chef or Puppet can automate the setup of your infrastructure. The other option is to adopt a practice called immutable infrastructure, which completely replaces, instead of updates, an existing part of your infrastructure, making deployments less complex. Replacing a system at the lowest level possible forces you to automate every deployment step.


Get your production and nonproduction environments in sync
Usually, when you start CD, you see your non-production environment is not only simpler than your production environment – it is different because the people who have built it often are from different cultures inside the organization. The project team has a strong influence on the nonproduction environment while the operations team drives improvements in production. In the second generation of CD, we need to adopt the same culture on different parts of the pipeline, so they will be the same. It’s what DevOps is all about: Eliminating the finger-pointing.


First, you share the tool with others. Then, you share the culture. Immutable infrastructure, using resources such as Docker, offers a great opportunity to share the same culture between the project, development and operations teams.


Improve the quality of the automated test
One sure fire way to improve your CD pipeline is to bring the testing culture to a new level. It’s an evolutionary process.


First, you commit to testing, then you add testing on existing products, and eventually you design your product with automated end-to-end tests synched with the process. The benefits are clear: It’s more cost-effective to create a series of tests along a pipeline than to create individual tests as you go. Plus, each test will be cheaper to implement because it will be designed for this, and you will be able to go further in the test. More automated testing gets you to market faster and it frees up resources to do more high-value tasks. Additionally, product teams will be more confident in adding features because they know they will be tested more thoroughly.


Reshape your organization to take advantage of CD
A year or so after you start your CD project, it makes sense to redefine the roles and responsibilities of people in the process. This will align everything you do toward the delivery of new features. Your dev teams and operations team should be organized based on how they define their quarterly objectives. They may find they need new skills sets. As manual tests get replaced by automated tests, new roles may appear and others may disappear. There will be fewer people recreating the same thing, and more people will be charged with thinking and rethinking automation functions.


This won’t necessarily involve more outside training. Rather, it will spur more internal training – more knowledge-sharing sessions between all the skill sets of your organization. People working in different communities on different products will need to share knowledge to drive processes further.


Teams should organize brainstorming sessions to discuss ways to integrate more automation into their pipelines. For example, if one team at an ecommerce website company is working on an online shop for goods and another team is working on a ticket system for shows, the teams can learn from each other by comparing the performances of their pipelines. They can’t do this if they’re operating in silos.


Another way to promote knowledge sharing is to physically change the teams. Have members of one team shift over and join another. That way, teams will continually share best practices and challenge each other to innovate on their pipelines.


CD and the Cloud
Over the past few years cloud technology has made significant inroads into enterprise IT with proven public, virtual private and private cloud solutions from trusted vendors. The cloud has become the base of the new enterprise data center, while improvements in cloud technology and the subsequent increase in adoption provide an excellent platform for accelerating CD adoption.


Cloud technology, paired with containers and infrastructure-as-code, enables fast low cost access to infrastructure.  This makes it much easier and less costly to spin up the resources needed to deploy CD tools, provide production-like test environments and more frequently deploy code.


By leveraging the cloud, individual teams can establish proof of concepts for CD pipelines and empirically identify and implement CD best practices with minimal risk and time.  Even better, your organization can look to leverage a private or virtual private cloud platform to provide teams shared CD-as-a-Service.  CD-as-a-Service enables teams to rapidly access and implement CD capabilities without the cost of securing server resources and set-up and administration of CD tools.


If you are committed to accelerating a move from CI to CD and beyond, then evaluating a cloud-based solution is a must.  As a quick start option, most commodity CD tools, such as Jenkins, can be found in Pivotal, Amazon, and Microsoft Azure marketplaces.  On a larger scale you can seek to leverage an internal cloud to deploy and build-your-own or turnkey CD-as-a-Service solution.


Spread the word
While it’s valuable to share knowledge inside the company, it also helps all involved to promote a culture that shares information to the world outside. Encourage leaders of your CD projects to present what they’ve done in conferences. There are dozens of events each year where DevOps leaders exchange ideas and discuss best practices in the world of CD. The discipline is still pretty young, so professionals are anxious to learn about how their peers are doing and how they could do their own jobs better.


Sharing your company’s achievements in CD is good for the people and good for the company. The people get feedback from outside the organization. They get recognized for their quality work. And the company gets recognized as a forward-looking organization that is a positive place to work. Everybody wants to work at a cutting-edge workplace. Encouraging your workers to spread the word about CD will help bring in the best and the brightest in the business.


The bottom line: Continuous delivery work is never done. Organizations never master the function. But organizations can improve – continuously – if they challenge their own methods and share knowledge inside and outside their four walls.

Sacha Labourey founded CloudBees in April 2010, after almost a decade as a major player with JBoss. In 2001, he joined Marc Fleury’s JBoss open source project as a core contributor and implemented JBoss’ original clustering features. After the Red Hat acquisition of JBoss in 2006, Sacha remained JBoss CTO and eventually became co-general manager of Red Hat’s middleware division. Follow Sacha on: Twitter

Brian Dawson is a DevOps evangelist at CloudBees where he helps the community and customers in implementation of Agile, CI, CD and DevOps practices. Prior to CloudBees Brian spent more than 22 years as a software professional in multiple domains including agile development, CI, CD, QA, engineering and management. Follow Brian on: Twitter