DevOps工具链胜过现成平台

许多组织都在寻找一个可以购买和标准化的单一平台，但团队经常会在一个不适合他们的平台上挣扎。

译自 DevOps Toolchains Beat Off-the-Shelf Platforms 。

寻找企业级 DevOps 平台的浪潮正在形成，但有迹象表明，这些平台在性能上无法胜过将最佳单项工具组合起来的 DevOps 工具链。平台工程可能会进一步扩大平台和工具链之间的差距，为开发人员提供定制的、针对组织的预组装工具链。

DevOps 平台

DevOps 平台的概念比 DevOps 早了几年。当 DevOps 成为市场上必须具备的标签时，许多现有的用于工作项管理、版本控制和持续集成构建的一体化工具与 DevOps 保持一致。

对 DevOps 运动密切关注的人会明显注意到，这些工具的功能组中缺乏“Ops”。这些平台不包括运行手册、可观测性或基础设施管理等功能。

人们倾向于认为，将这些工具贴上“DevOps”标签是一个讽刺的营销策略。然而，使用 DevOps 这个名称的想法是帮助人们看到该产品可以成为 DevOps 工具链的一个重要部分。

通用 DevOps 平台通常涵盖计划、开发、版本控制和构建，有些的覆盖范围比其他的小。平台的范围越广，完成工作所需的努力就越大。

为了说明这一点，你可以创建一个基本上是执行任意命令的任务运行器的平台。这可以满足企业对 DevOps 平台的定义。你的部署流水线将包括一个命令序列，使用命令行界面和 API 调用来执行每个步骤。这样一个平台的价值很低。

所有流行的 DevOps 平台在工作项管理或持续集成构建等领域都有核心优势。在核心之外，其功能就不那么有用了。这不是一个弱点，因为成功的组织使用 DevOps 平台来建立基础，然后用专业的工具来补充，这些工具可以提高他们交付软件的能力。他们不依赖将其作为 DevOps 的唯一工具。

这就是为什么所有这些平台都提供了集成和扩展机制。

直觉和研究

当你使用更多的专业化工具时，需要进行一定程度的集成。组合后的功能集必须带来生产力和性能改进，以抵消互操作性工作。如果你使用单一的DevOps平台，就不会有互操作性问题，但你的功能集将限于通用工具中可用的。

但是，与更丰富的功能集相比，互操作性问题有多大？

如果你创建一个由独立的工作项管理、版本控制、构建和部署工具组成的部署流水线，你可以形成一个整洁的顺序工具链，每个阶段都有清晰的交付。提交引用工作项。每个提交都会触发构建。构建过程创建的工件被上传到部署工具，并可以导致零接触部署到第一个环境。

通过这种轻量级的交付，多个工具组成的工具链优于通用平台就不奇怪了。这是经典的工具箱与瑞士军刀的场景，只不过我们谈论的是对软件交付至关重要的工具。你可能会带上一个瑞士军刀去野营旅行以备不时之需。然而，如果你的 builder 到现场时除了一个小的多功能工具外别无他物，你会谅解他对结果的顾虑。

“2023 年持续交付报告”证实了我们的直觉。报告发现，如果你使用更多工具，你成为顶级表现者的可能性会加倍。你的前置时间会更短，部署频率更高，服务恢复更快。报告发现 CI/CD 工具预测较高的表现，并且使你成为低端表现者的可能性大大降低。

报告中的一个警示故事是，自托管太多 CI/CD 工具会降低性能。当团队自托管超过两个 CI/CD 工具时，这一点显而易见，表明运营负担变得分心。由于大多数这些工具都以托管解决方案的形式提供，远离自托管工具可以减轻负载。

平台工程可以提供帮助

平台工程与 DevOps 运动深度相关。该概念基于 Matthew Skelton 和 Manuel Pais 关于团队拓扑的工作，其中平台团队的目的是“使面向流的团队(如特性团队)能够相当自治地交付工作”。

平台工程团队通过抽象掉开发团队必须处理的某些复杂性，试图减轻开发团队的认知负担。平台团队可能关注的一个关键领域是部署流水线。假设开发人员可以访问由 DevOps 平台和许多最佳单项工具组成的顺畅 DevOps 工具链。在这种情况下，他们可以在没有互操作性和运营负担的情况下交付软件。这使团队可以获得“持续交付状态”报告的积极益处，而不会产生不利影响。

内部开发者平台可以按需生成整个部署流水线，部署和基础设施自动化准备就绪。开发人员可以创建流水线和项目骨架，然后开始开发第一个功能。你可能会称之为“即时 Hello World”，因为你可以立即将空应用部署到生产环境。

与买下架的通用产品相比，内部开发者平台是针对组织需求定制的，并且可以响应必要的变更。

根据我们对 DevOps 工具链的评估，你可以看到为什么平台工程存在于 48% 的高绩效 DevOps 组织中，根据 Puppet 的“平台工程状态报告”。