GitLab似乎对CloudBees和Jenkins有点困惑。别让他们把你搞糊涂了。我不得不说，GitLab关于我们在CloudBees和Jenkins的帖子在这里引起了一些令人挠头的事情。这应该是一年的更新，他们奇怪的詹金斯帖子去年跟随詹金斯世界，我们刚刚采取了大步。但是今年的帖子太过冷淡了，我们认为如果我们不努力去理清那些明显的错误，这将对我们的客户和整个行业造成伤害。好吧，让我们把要点说清楚。詹金斯不是云蜂，云蜂也不是詹金斯。首先，这两个帖子都把詹金斯和云蜂混为一谈CloudBees是一家产品公司，它构建商业软件，帮助公司进行DevOps和持续集成并大规模交付。Jenkins是一个开源项目，是用于持续集成的最广泛的自动化服务器，持续交付和其他DevOps自动化任务在全球范围内，并从根本上使这些实践在其前身Hudson项目于2000年代中期创建以来得以实施。CloudBees自2010年以来一直是Jenkins的主要企业赞助商，多年来聘请了许多顶尖的贡献者，并提供了世界上最具詹金斯认证的开发人员支持工程师，以及詹金斯的传奇创造者川口一介，自2010年成立以来，CloudBees一直在担任不同的高级职务，包括2018年Jenkins World的首席技术官和今天的首席科学家，但CloudBees并不拥有Jenkins，最初也没有创建Jenkins，也不控制其社区。因此，把今年CloudBees发布的与Jenkins无关的商业产品称为Jenkins的未来完全是误读。CloudBees目前部署最广泛的产品CloudBees Core确实建立在Jenkins之上并与Jenkins进行互操作，使企业能够以可管理、可扩展和安全的方式跨多个团队和项目运行基于Jenkins的CI，有时也可以运行CD，但CloudBees的产品不是Jenkins。CloudBees还拥有CloudBees Flow和CloudBees加速器-通过Electric Cloud获得-稍后将详细介绍。CloudBees的推出和CloudBees的代码共享也是通过两个较小的收购实现的。最后，CloudBees为Jenkins提供了点菜支持。 SDM是新的，是对现有工具链的补充，而不是一体式的。最近的GitLab文章似乎认为CloudBees宣布的软件交付管理（SDM）的新类别是Jenkins（？！？记住-我们不是Jenkins）计划做他们想做的事情-创建一个一体式的替代品，取代目前大多数企业使用的所有现有多供应商软件开发工具链。好吧，我们没有。Jenkins项目和CloudBees公司都非常相信与企业客户现有工具的互操作性和协调性，投资和使用最佳工具。我们认为一家公司不可能或不希望取代SDLC的所有工具。GitLab继续宣称并发布"路线图"，他们打算用一系列令人眼花缭乱的类别来取代它们。其中许多类别都有多个优秀的供应商和项目，这些供应商和项目的成熟度高达数百人年。我们相信开发人员希望挑选出在高度创新的DevOps领域不断涌现的最佳解决方案，而不是依赖预定义的最低公分母解决方案。自4月份以来，我们在多个公共论坛上明确指出，软件交付管理是一个新的类别，它整合了软件交付中涉及的所有工具的数据，并针对这些工具应用业务规则和策略，以便在软件团队之间提供更高级别的可见性、协作和控制，产品、功能。正如Jenkins在SDLC中的协调一样，SDM在更高的业务级别和更左的功能（如产品管理）和更右的功能（如合规、营销、销售和支持）进行协调，所有这些都让您管理软件交付的业务。我们正在将SDM集成到客户使用的最流行的工具中，并构建一个应用程序框架，使CloudBees SDM生态系统能够像Jenkins的plugin生态系统一样发展壮大。诚然，SDM将协调跨SDLC类别，其中CloudBees确实有一个产品（即CD with Flow），可能是开源项目的主要赞助商（即Jenkins本身），也可能会收购新产品。但是，如果我们已经是领头羊，可以收购领头羊，或者品类是新的或者现有供应商的服务不足，我们才会拥有或购买我们自己的产品。这不是一个万能的策略，也不像GitLab的公开立场，有点难以相信。下面是一个简单的图表，它显示了SDM作为一个新类别添加的内容与传统的、现在被添加到SDLC工具链中的东西之间的区别。就像GitLab一样，他们正在试图替换现有的工具链。有了SDM，我们试图在它的基础上增加一些非常需要但还不存在的东西。这个价值是关于所有筒仓和异构最佳工具链之间前所未有的可见性、协作和控制。  詹金斯会做CI和CD。CloudBees的客户使用CloudBees核心来管理Jenkins。Flow和Jenkins X使CloudBees的CD更好。GitLab声称，我们收购Electric Cloud是为了给之前"只能做CI"的Jenkins添加CD，Jenkins X是为了"匹配"GitLab的CI和CD组合。这既过于简单，又扭曲。请容忍我：我非常相信爱因斯坦的名言"尽可能简单，但绝不简单！"Jenkins不是CI，它是一个编排引擎，它执行可以实现很多自动化的管道。它恰好在CI中得到了最广泛的应用，因为它是在DevOps自动化的早期发展起来的，从commit->test->artifact开始。它还可以用于交付甚至部署，而我们的许多客户在收购Electric Cloud之前就是这样做的。但是，不可否认的是，在手工制作Jenkins管道时，部署到传统ops环境中所涉及的问题涉及到大量的手工工作。同时，Electric Cloud创建了Flow，它有很多内置的方法来建模目标环境、管理凭证等，使得大规模地进行连续交付和发布自动化（CDRA）变得更加方便、易于管理和安全。为了做到这一点，它还必须有一个管道引擎，因此一些EC Flow客户也将其用于CI，但它对CI的关注不足意味着大多数人使用Jenkins或其他东西来进行CI，而Flow用于CD。这不干净。我们收购了EC是因为他们做CD的方式是同类中最好的，通过及时将其与Jenkins、Jenkins X和CloudBees的其他公司紧密结合，我们可以为所有类型的环境和软件开发提供最佳的CI/CD整体解决方案。我们发现GitLab声称我们的目标是匹配它们，这很有趣，因为Forrester在收购EC之前就在CDRA上比较了Electric Cloud、CloudBees和GitLab。弗雷斯特波™ 版权归Forrester Research，Inc.Forrester and Forrester Wave所有™ 是Forrester Research，Inc.Forrester Wave的商标™ 是Forrester在市场上的号召的图形化表示，并使用详细的电子表格绘制，其中包含公开的分数、权重和评论。Forrester不认可Forrester Wave中描述的任何供应商、产品或服务。信息是基于最好的可用资源。意见反映了当时的判断，随时可能改变。好吧，好吧，克里斯蒂娜。但是插件呢？嗯，GitLab也需要插件。更严重的是，我们确实认为GitLab很可能会成功地在一些现有类别中开发出更好的新工具，并欢迎它们出现在DevOps市场中。我们的客户选择GitLab工具作为其工具链的任何一部分，将能够使用CloudBees SDM和Jenkins来跨越这些工具和其他最佳供应商的工具。我们并不认为CI或CD会成为GitLab落后的赢家之一，但SDM是整个工具链之上的一个层，无论存在什么。希望这篇文章能澄清GitLab可能造成的一些困惑。给我写信cfrln@cloudbees.com如果你想和我聊聊这些或者在twitter@cfrln上与我交流。-克里斯蒂娜·诺伦