GitLab seems to be a little confused about CloudBees and Jenkins. Don’t let them confuse you.
I have to say this post by GitLab about us at CloudBees and Jenkins caused some real head-scratching here. It’s supposedly a one year update of their odd Jenkins post last year following Jenkins World which we just took in stride. But this year’s post is so off that we thought it would be a disservice to our customers and the industry at large if we didn’t try to clear up what’s just plain wrong.
OK, so let’s get some key points straight.
- Jenkins is not CloudBees and CloudBees is not Jenkins.
First off, both posts conflate Jenkins with CloudBees.
CloudBees is a product company that builds commercial software that helps companies doing DevOps and continuous integration and delivery at scale. Jenkins is an open source project that is the most widely used automation server used for continuous integration, continuous delivery and other DevOps automation tasks around the world and essentially enabled these practices to take hold since its predecessor project Hudson’s creation in the mid 2000s. CloudBees has been Jenkins’ primary corporate sponsor since 2010, employing many of its top contributors over the years and offering the most Jenkins certified developer support engineers in the world, and Jenkins’ legendary creator, Kohsuke Kawaguchi , has had different senior roles with CloudBees since nearly its beginning in 2010 including CTO as of Jenkins World 2018 and Chief Scientist today - but CloudBees does not own Jenkins, did not initially create it and does not control its community. So to talk about CloudBees’ non-Jenkins related commercial product announcements this year as the future of Jenkins is a complete misread.
CloudBees’ most widely deployed product today - CloudBees Core - does build on and interoperate with Jenkins to enable enterprises to run Jenkins-based CI, and sometimes CD, across many teams and projects in a manageable, scalable and secure way - but CloudBees’ products are not Jenkins. CloudBees also has CloudBees Flow and CloudBees Accelerator - acquired with Electric Cloud - more on that later. CloudBees Rollout and CloudBees CodeShip came via two smaller acquisitions too. Finally, CloudBees offers a la carte support for Jenkins .
- SDM is new and complementary to existing toolchains, not an all-in-one.
The recent GitLab post seems to assume that CloudBees’ announcement of the new category of Software Delivery Management (SDM ) is Jenkins (?!? remember - we are not Jenkins) planning to do what they are trying to do - create an all-in-one replacement for the entire existing multi-vendor software development toolchains in use in most enterprises today. Well, we’re not. Both the Jenkins project, and the CloudBees company, believe deeply in interoperability with and orchestration of our enterprise customers’ existing tools investment and use of best-of-breed tools. We do not think it is possible or desirable for a single company to replace all the tools of the SDLC. GitLab continues to claim and post “roadmaps” with a dizzying array of categories they intend to replace. Many of these categories have multiple great vendors and projects with many hundreds of person years of maturity. We trust developers want to pick and choose the best solutions that keep emerging in the highly innovative DevOps space, not rely on a predefined lowest common denominator solution.
What we have clearly stated in multiple public forums since April is that Software Delivery Management is a new category that consolidates the data from all of the tools involved in software delivery, and applies business rules and policies against them, to provide higher level visibility, collaboration and control across software teams, products, functions. Just like Jenkins orchestrated across the SDLC, SDM is orchestrating at a higher business level and across functions further left like product management and further right like compliance, marketing, sales, support - all to let you manage the business of software delivery. We’re integrating SDM to the most popular tools in use at our customers and building an app framework to allow a CloudBees SDM ecosystem to grow and thrive just as the Jenkins’ plugin ecosystem has in the past.
Admittedly, SDM will orchestrate across SDLC categories where CloudBees does have a product (i.e. CD with Flow), may be a major sponsor for an open source project (i.e. Jenkins itself) or may acquire a new product. But we will only have or buy our own product in a category if we are already the leader, can acquire the leader or the category is new or underserved by existing vendors. That is not an all-in-one strategy and nothing like GitLab’s public and somewhat hard to believe position.
Here is a quick diagram to show the difference between what SDM adds as a new category and what is classically and now being added left and right to the SDLC toolchain. All in one’s like GitLab are trying to *replace* that existing toolchain. With SDM, we are trying to add value on top of it with something that is sorely needed but does not exist yet. This value is about unprecedented visibility, collaboration and control across all silos and heterogeneous best-of-breed toolchains.
- Jenkins can and does do CI and CD. CloudBees’ customers using CloudBees Core to manage Jenkins do both. Flow and Jenkins X make CloudBees’ CD even better.
GitLab claims our acquisition of Electric Cloud was to add CD to a Jenkins that previously “could only do CI,” Jenkins X was to “match” GitLab’s combination of CI and CD. This is both oversimplified and distorted. Bear with me here: I am a big believer in Einstein’s famous quote “as simple as possible, but no simpler!”
Jenkins isn’t CI, it is an orchestration engine that executes pipelines that can do a lot of automation. It just happens to have been most widely used for CI as it grew up during the early years of DevOps automation that started with commit->test->artifact. It can also be used to deliver and even deploy - and many of our customers did just that prior to our Electric Cloud acquisition. But, admittedly, the issues involved in deploying to traditional ops environments involved a lot of manual work to handle when handcrafting Jenkins pipelines. Meanwhile, Electric Cloud created Flow that had a lot of great built-in ways to model target environments, manage credentials, etc. making it much more convenient, manageable and secure to do Continuous Delivery and Release Automation (CDRA) at scale. To do that, it also had to have a pipeline engine so some EC Flow customers used it for CI too - but its lack of focus on CI meant that the majority used Jenkins or something else for CI and Flow for CD. This is not clean cut. We acquired EC because their way of doing CD is best in class, and by in time integrating it more and more tightly with Jenkins, Jenkins X and the rest of CloudBees, we can offer the best overall solution for CI/CD in all types of environments and for all types of software development.
We find GitLab’s assertion that our goal is to match them quite amusing given how Forrester compared Electric Cloud, CloudBees and GitLab on CDRA just *prior* to our acquisition of EC.
The Forrester Wave™ is copyrighted by Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester Wave™ is a graphical representation of Forrester’s call on a market and is plotted using a detailed spreadsheet with exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in the Forrester Wave. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.
Okay, okay, Christina. But what about the plugins?
Hmm. GitLab needs plugins too.
More seriously, we do think it likely that GitLab will succeed in doing better new tools in some existing categories and welcome their presence in the DevOps market. Customers of ours who choose GitLab tools as any part of their toolchains will be able to use CloudBees SDM and Jenkins across these tools and tools from other best-of-breed vendors. We don’t happen to think that CI or CD will be amongst the categories where GitLab comes from (way) behind to win, but SDM is a layer above the whole toolchain no matter what lives there.
Hopefully, this post clears up some confusion that GitLab’s may have created. Drop me a line at cfrln@cloudbees.com if you want to chat about any of this or interact with me on twitter @cfrln .
- Christina Noren