CloudBees’ tools for for automating software delivery aim to build on DevOps, continuous integration (CI) and continuous delivery (CD) to make it easier for companies to manage their software development processes, with customers including Capital One, Bosch and Allianz. ZDNet talked to CloudBees co-founder and CEO, Sacha Labourey, to find out more.
ZDNet: Tell me a little about your company
Labourey: I co-founded CloudBees in 2010. We always wanted to help developers deliver software faster. And we kind of had two half-lives, the first from 2010 to 2014 when we were a platform distributor and vendor. And we had a complete offering to build, test and deploy code in the cloud. It was all integrated and it was really ahead of its time because products like that were only focused on deployment — you didn’t have the full life cycle. And the key part of this was an automation server called Jenkins.
What was interesting back then was the feedback from enterprises. They said they loved it, they loved the idea of going faster but they weren’t using it in the cloud to begin with. They loved it but it was never quite right for them.
So, in 2014 we decided to focus on CI/CD and DevOps and that’s what it’s been for the last three years: the hub of CI/CD, the hub of DevOps.
I am interested that you use Jenkins because that is not a platform you hear a lot about.
The size of Jenkins we have out there is pretty impressive. We have more than half a million nodes at any point in time computing jobs so it’s pretty massive.
The role that Jenkins fulfils comes from a piece of software called the Orchestrator. Now, in DevOps you have lots of different tools. You have some tools to do load testing, code repositories, binary repositories and so on. Jenkins is not competing with any of those. What it’s doing is it owns the workflow definition which we call a pipeline and the pipeline defines how software can be automated through all the steps — to go through all of those tools.
It has, actually 14,00 integrations with different tools. And it knows how to integrate all of those, which is important for enterprises because they tend to have one of each and it knows that it needs to call a specific tool. It’s really this big Orchestrator that owns the IP of the organisation — how they build software. That’s a pretty strategic tool.
That’s why we call it the hub of DevOps. It’s not just a build or a test or a staging or any specific tool. It’s just orchestrating all of those.
Jenkins is the only tool that will know exactly what the developer did as part of what team for what ticket, what testing it went through, whether it’s running in production right now and what performance it’s having in production and so. It has complete visibility over all the things that took place from its inception to production.
How does it work over the course of the lifecycle?
Specifically, when we talk to companies, they have been doing CI. We usually don’t talk to companies just doing CI, because CI tends to be the early steps in the lifecycle where you see developers doing build and test. And the reason for that is because it’s perceived as being a non-critical, non-strategic step.
And really, that is how Jenkins was released and adopted by so many companies — in a very ad-hoc fashion where developers would take a computer, install Jenkins on top, put it under the desk and here we go.
And then, as the DevOps movement started to heat up, companies and teams started to push this process further. Let’s automate some testing, let’s go and do more sophisticated testing and maybe go to staging and so on and so on.
You could see this moving further and further and, in doing so, it proceeded from Software Integration to Continuous Delivery. What seems to be just a simple change in a letter, from CI to CD, happens to be a much more impactful change. If what your company starts doing is truly continuous delivery, it means that the only way you’re going to be changing this running in production is by operating this pipeline and bringing this up to running in production.
And that means that Jenkins or your CI/CD environment and is not just a computer under a desk anymore. It becomes a strategic system that cannot go down because if it does you cannot push through any changes to production.
That radically changes the perception of Jenkins to be not just be a tool for developers but to become a business-critical system to IT.
It takes some time to move from an unstructured method of adoption to something that is really core to what IT is doing.
The next step in this evolution is to provide a centralised CI/CD environment for all teams. You really need to provide DevOps for everybody.
And so, what we see is the creation of a centralised DevOps team which is part of shared services.
When a new product needs to be developed, the business might say, “Well, we need a new, ecommerce, mobile application”, you can create a new team and that team already has access to the right tools. They are already trained on those tools and they can get going.
That’s really the next step: enterprise-wide enablement and making sure that the company has one way to train and on-board new engineers as well as create a new project.
And it’s not just tools, it’s actually a very sophisticated transition.
Of course, companies that make this transition, hope that things are better. They get a sense that things are better, but they don’t really know.
So, on top of this offering we have something called DevOptics where we have helped leverage the system of record that I was talking about. The object is to record all those signals that are going inside and outside your organisation and to record how your organisation is performing.
It’s a big transformation. But your organisation is a big cascade of information and this is a way to really understand it and from there how to make it better in delivering.
What about governance?
The last step is really around governance. Once you get to the right point — and every company will get there at their own pace — the next step, once you have all these streams of information, is to understand what is happening.
Once you understand that you are empowered by developers to be creative, to be efficient at a high velocity, you don’t want to break that but, at the same time, you have policy and regulations to follow. And that is what we are building now — a system to offer governance and be able to assure peace of mind. But, at the same time, offer the power and the features for them to be able to differentiate themselves in the market.