CloudBees CEO reveals plans for CI/CD tools, Google project

SAN FRANCISCO -- CloudBees is a drastically different company than it was a year ago, after several acquisitions to help navigate evershifting trends in CI/CD tools. The next task for CEO Sacha Labourey is to bring them all together, and up to speed with where DevOps will be another year from now.

To that end, CloudBees opened an early preview program at its annual user conference here this week for its next-generation CI/CD tools for DevOps shops, which it calls the software delivery management (SDM) platform. CloudBees first discussed SDM publicly as an overall strategy in April, but now it has concrete plans for a software-as-a-service product that will blend IP from CloudBees Core, the Jenkins X open source project, Codeship, Electric Cloud, DevOptics and Rollout, most of which CloudBees released or acquired in the last 12 months and maintains as stand-alone products. CloudBees also kicked off work this week with Google to develop CI/CD tools for the Anthos hybrid cloud platform.

Meanwhile, it's not lost on Labourey that tools such as SDM draw upon concepts such as tests in production, feature flags, on-demand automated hybrid cloud infrastructure and value stream management, but these still lie far beyond the maturity level of most enterprise customers.

In this Q&A, Labourey provides further details on the CloudBees CI/CD roadmap, how the company plans to address lagging enterprise DevOps maturity, and where all of this leaves Jenkins as CloudBees diversifies its strategy.

What do SDM early access users get access to at this point?

Sacha Labourey

Sacha Labourey: They'll get access to the first feature of the SaaS product, a Product Hub. The Product Hub makes it possible to start organizing your products, your features and repositories, hooking together all of the streams from JIRA or GitHub or Jenkins into one assembled thing. We call it a nucleus, this assembly of different DevOps systems.

What kinds of trends among customers does SDM address?

Labourey: Companies have deployed a CI/CD strategy, it took them some time, and I would argue that a lot of them are not yet fully doing CI to start with. There is a slow train of maturity taking place across the market. And companies end up with lots of silos of information, lots of teams, lots of projects and applications. Which is all fine because what you wanted in the first place was for those teams to be creative and iterate faster. But the countereffect is that all of the ways you had put in place before to control and measure [results] disappear.

Since we are at the center [of those new environments], it's possible for us to capture all of their signals and store them in a structured fashion, kind of a normalized data model for DevOps. And from there, we're able to extract insight out of this ocean of signals, and to connect processes among different teams, different organizations, and enforce policies.

Because a lot of people focused on velocity, but quality is equally important.

Labourey: Yeah, quality and compliance. Imagine you work for a big bank, and you have a few teams starting to do continuous delivery at a good velocity. And then you deploy that to 5,000 developers, and you start having bad dreams, because how do you make sure the crown jewels [of your company] are being protected? Some companies have sold [a strategy that] the way you do that is to gate the behavior -- you say, 'Once you're ready, you come to see mom, and you tell her you want to go to production.' That's essentially the antithesis of DevOps in some ways, because it's adding this huge friction at the end. We want to force the right behavior before that event.

Some IT consultants now believe that the concept of environments as separate siloed things is broken. Does that match your SDM approach?

Labourey: The old way we were able to do things with Chef and Puppet five to 10 years ago, is to create a staging environment by using scripts, then deploy an application to do testing, then you create a separate environment for production. Thanks to containers, now the very first step in that lifecycle is to create a complete environment in a box, and lock it down as something that can be instantiated again and again, like [a set of] parallel universes. The message is, instead of doing things like continuous delivery, in stages, you do progressive delivery -- release to 2% of users, and observe how things are doing compared to a baseline. So essentially, the good old joke of testing in production is becoming a reality.

How many CloudBees customer environments actually look like that?

Labourey: Very few. We're seeing companies that can barely do CI, and we've got organizations playing with some super-advanced scenarios. It means we need to be very much ahead of our time with lots of innovation, but at the same time, the type of problems we solve in the field are, a lot of the time, much, much simpler or related to a lower maturity level.

How will SDM bring customers along that maturity curve?

If the system can tell you, 'You have 20 things to work on, but those two? You need to solve them now, because if you do, it's going to enable a lot more work in other teams.' Those are the kind of things you can see if you have a bird's-eye view of the world.

Labourey: First, we can hook into their existing environment. We can come in and start listening to signals in an easy way, and then we can start giving visibility into how teams are performing, and then you can start maturing behavior. For example, as a developer, if the system can tell you, 'You have 20 things to work on, but those two? You need to solve them now, because if you do, it's going to enable a lot more work in other teams.' Those are the kind of things you can see if you have a bird's-eye view of the world, and you can read those signals.

That's a prime issue with engineering -- we see it at CloudBees as well. Sometimes you have this perception that your teams are not being productive, and you don't know why. It's pretty hard to analyze accurately.

How did the Google partnership come about, and what's the goal there?

Labourey: For Google, I think the interest is dual. First, they have a positive relationship to open source. And I think some of that is a good positioning from Google, because of some of the stories we heard about Amazon, for example. They care about developers, and Jenkins X is appreciated by developers, so it's a good angle.

But maybe more importantly, a key value of Jenkins X is this ability to deal well with multiple environments. Google has a strategy where Anthos can deploy on premises or on different clouds. If you also have a CI/CD layer that's [geared toward] multiple environments, then you can say, 'All of my developer preview environments are going to be on Google Cloud, but then my deployment happens on premises, and fails over on AWS.' That's what Jenkins X does very well.

What will be the difference between what Google and CloudBees will offer and a customer just putting Jenkins X and Anthos together themselves?

Labourey: We're going to be on Google's Marketplace, which means that a customer really comes away a lot of things quote-unquote for free in terms of installation and setup. That's a lot of the work we do, but we're also working with Google on a SaaS-based approach, to make it even easier.

Where does all of this leave Jenkins as an open source project? Obviously, CloudBees is expanding beyond Jenkins, and there's a plethora of new CI/CD tools. What is next for Jenkins, in itself?

Labourey: That plethora of tools is mostly in the container space, because it's the new way. But that's still by and large not what people are doing. Jenkins can work with containers, but it can do a lot more things. We still have a team and lots of contribution going into Jenkins because this is not going to go anywhere anytime soon. As I was saying, it's a long train of DevOps [maturity] for users.