A Deep Dive into Continuous Integration and Continuous Delivery

We recently visited with CloudBees CEO Sacha Labourey to discuss the growth of continuous delivery (CD) as companies continue to adopt a DevOps culture. The CloudBees Jenkins platform implements continuous integration (CI) and continuous delivery utilizing the Jenkins open source automation and orchestration technology.

ADM: What is Jenkins CI and how does it relate to CloudBees? 

Labourey: Jenkins is an open source project. It had its origins in continuous integration (CI) - which deals primarily with the automation of development processes: build/code integration/test automation. With CI now so well-established, many organizations are realizing that the automation they have benefited from in the development process can be extended further into the software delivery process, through staging and into production. 

This is called continuous delivery and it has the ability to greatly accelerate the entire software delivery process. Indeed, companies that have adopted it are way more agile than their peers, can respond to market dynamics much more quickly and can push code to production quickly and analyze results to see if any positive impact on their business. 

Jenkins enables this because it orchestrates software delivery processes. Teams can continue to use - or can adopt - any of the popular development technologies they choose. With over 1,000 plugins, Jenkins supports almost any technology available today that is used in the software delivery process.

ADM: How has CI changed in the past five years? 

Labourey: It has become the de facto standard for organizations that produce software. It is no longer something new and innovative - CI is widely accepted. Jenkins was really the catalyst behind the rapid move to CI and CI becoming such a well-accepted development practice. It also proved how much more productive automation makes the development process. Teams can deliver code more quickly and with higher quality. 

As already stated, that has made it the catalyst for continuous delivery practices - extending the automation through the entire software pipeline.

ADM: What’s the difference between continuous integration (CI) and continuous delivery (CD)? How does Jenkins fit into that puzzle? 

Labourey: CI was always focused on the development part of the software delivery process. CD extends automation throughout the entire software development lifecycle. CD is really the industrialization of the software delivery process: it takes software delivery from a messy and oftentimes manual series of processes, fraught with errors and integration issues to a process that is automated, more predictable, repeatable and that produces higher quality software, much more quickly.

Jenkins enables both CI and CD because it has the ability to orchestrate and automate all parts of the software delivery process. It isn't just a development tool - though that is where it had its origins.

ADM: Why are so many enterprises adopting continuous delivery and DevOps?

Labourey: CD adoption is pervasive right now. The clear trend is to automate the entire software delivery process to realize the advantages of faster time to market, greater efficiencies and more business agility. 

In turn, CD enables transformation to a DevOps culture. DevOps is not something you implement with a certain tool - it is a culture of teamwork and shared goals. Development and operations work together with the common goal of smooth, uneventful and accelerated software delivery. No finger-pointing, but shared goals and shared responsibility in producing quality software.

CD and a DevOps culture deliver a competitive edge, enabling companies to respond much more quickly to customer needs, competitive pressures and realize faster time to innovation.

To be clear, we are not talking about 10% or 20% speed improvement. We are talking magnitudes of 10x. This means the impact of CD goes way beyond what an "optimization" would bring, such speed improvement opens the door to a new way of thinking about software and the value it can bring to the business. The way to think about it is that planes were not just "faster trains," they truly enabled something new. 

ADM: We hear about companies like Netflix deploying 100s of times a day, is this realistic for other companies? 

Labourey: Yes. But you don't flip a switch and get there overnight. CD is not something you just decide to "do." 

To adopt CD, you have to analyze your entire software delivery process, identify ways to automate manual processes, eliminate inefficiencies and redundancies, implement changes in those processes - and automate them. While doing this, you also have to break down cultural barriers and get teams working together that haven't typically worked together (development, IT operations). 

ANY company can do this. The question becomes, are they committed to doing the hard work required to do it? Does their management and culture support it? Does the executive team understand they need to support, even mandate, change to CD practices? Over time, reworking the software delivery process and the implementation of automation enables the transition to CD. This can happen within any organization - large or small. The issue is, is there a commitment to enable that change? It takes a lot of hard work to make it happen.

The other significant change is that you can't get to deployment 10's or 100's of times a day with a legacy process - that is, the massive, major releases that companies used to do. Today it's about pushing incremental changes to production quickly - in some companies, the minute the developer codes a change and the new code passes the required tests, it is in production. You can't deploy 100s of times per day if you are deploying a massive codebase.

But the "software unicorns" with their impressive yet intimidating release figures (Amazon, Etsy, Facebook, etc.) can also play a negative role in making teams feel they'll never be able to reach such levels of automation. There is absolutely no need to reach or even get close to the metrics of those software unicorns to start seeing huge benefits. Any step towards CD is a good step and brings value.

ADM: In your opinion, what would a successful application development workflow and pipeline look like? 

Labourey: Ideally, a pipeline where all stages have been automated and where initial feedback about ~90-95% of the typical bugs/issues can be raised to the teams in less than an hour. This insures developers get a very fast feedback loop, as they are still focused on the task at hand. More sophisticated testing can take more time but most typical issue should be raised fast. 

ADM: You recently announced that 13 resellers (a 50% increase in Q4) are now partnering with CloudBees to sell Jenkins CI/CD solutions, what do you think is driving this growth? 

Labourey: It is clearly the trend to implement CD practices and attain a DevOps culture. Jenkins is at the forefront of enabling all of this. The value that CloudBees adds on top of Jenkins is additional functionality for enterprise requirements and formal technical support for Jenkins and its ecosystem of plugins. CloudBees enables enterprises to scale up Jenkins and fully optimize the use of it across the organization.

As we discussed here, moving towards CD requires a lot of work and commitment and it is very easy to get distracted with the daily routine and ongoing challenges all organizations face. To that end, resellers can act as a great change agent and can make sure they keep organization on track of their CD journey. It is very hard to succeed in such a transition without help.

ADM: What other trends do you see in the industry that developers should be keeping an eye on? 

Labourey: A number of parallel phenomenons are growing very fast: containers, cloud infrastructure and continuous delivery. Those phenomenons are slowly colliding and creating the perfect storm of conditions to dramatically transform the way we produce software.