五种方式降低“开放式DevOps平台”成本及常见DevOps工具对比

五种方式降低 “开放式 DevOps 平台” 成本

即使是最成功的 DevOps 实践也可以变得更精简、更高效。关注以下这五个方面提升开放式 DevOps 平台的成本效益。

一个开放的 DevOps 平台可以给企业带来明显的好处——更快的发布时间，更好的安全性，以及更令人愉悦的开发体验。但成功的 DevOps 团队总是希望更进一步，实际降低软件开发成本。使用 DevOps 平台团队可占据先机，因为他们不再需要花费金钱和时间来支持和维护多个工具链。

在此基础上，关注以下五方面，进一步降低开放式 DevOps 平台的成本：

1. 云。硬币都有两面性，“云” 所提供的所有灵活性也有潜在的黑暗面 ——不必要的云服务使用。随着任何人都可以通过线上支付轻松购买公有云资源，"设置它并忘记它 " 有点太容易了。如果不加以控制，云成本甚至会比本地部署更大。云的定价包括其他因素，如存储、网络、监控和备份等服务。云服务的无序使用也有一些 SaaS 实例，如 Salesforce、Adobe 或任何其他在线服务，企业常常为新用户账户付费，但实际上并没有使用它们。监控云的使用情况可以对紧张的 DevOps 预算提供一些洞察。
2. 工具链。即使是一个可靠的 DevOps 平台，也会隐藏有一些不必要的服务，所以应该查看一下你拥有许可的全部内容，确保它们都在使用。如果你仍然不确定，我们的工具链计算器会清楚地分解这一切。
3. 遗留系统。维护老旧的基础设施需要大量资金。倘若您不相信，可以试着以开发人员平均工资雇佣一个 COBOL 开发人员（剧透警告：千万不要...）。像 Amazon 和 Facebook 这样具备互联网先天优势的领先公司，他们可以在应用程序中构建相对较新的系统和 DevOps 功能，因为它们无需担心旧系统。随着时间的推移，旧系统的真正成本是巨大的。从维护系统所需的额外资源到生产力的损失，它们会阻碍企业对可以实现长期增长的投资，阻碍那些从长远来看会增加收入的项目发展。
4. 手动任务。即使是一个成熟的 DevOps 团队也会承认，并不是所有的事情都是自动化的——但它的确、应该是的。“测试” 是最现实的问题——在 GitLab2020 年全球 DevSecOps 调查中，47% 的受访者指出测试是发布延迟的最可能原因，这比 2019 年仅下降了 2%。所有人都同意需要在各环节进行更多的测试，但在大多数公司，测试自动化仍待实现；GitLab 调查发现，只有 12% 的受访者表示他们的测试是完全自动化的。
5. 时间成本。时间等于金钱，降低 DevOps 成本的最后一步必须包括寻找效率低下的流程。一个明显的地方是代码审查。我们的调查显示，代码审查对于成功的 DevOps 来说至关重要，而且发生的频率要高得多（许多团队的代码审查频率高达每日）。但调查也显示出围绕代码审查的强烈挫折感：参与的人太多，没有明确的流程，对其重要性缺乏共识。换句话说，在许多组织中，代码审查是一种时间上的浪费，这导致了金钱的浪费和机会的错失。

常见 DevOps 工具对比

“透明” 是极狐和GitLab 公司的核心价值之一，正是本着这种精神，我们评估和阐述了 GitLab 在行业竞争中的地位，希望这种透明度不仅能帮助团队做出正确的决策，还能帮助我们确定在哪些方面可以改进我们的产品。

任何竞争性的比较要想有效，必须是公平、准确和易于理解的。无论是比较三个版本的 Jenkins 和 GitLab CI/CD，还是比较 SDLC 中的其他 DevOps 工具，我们都努力确保实现竞争性比较的这三个关键目标。

保持公平

竞争性比较中最大的挑战之一是保持公平和可信度。竞争性比较标准的选择起着重要作用，因为它必须是公平全面的，而不是只对本产品有利。很多时候，厂商将竞争性比较标准局限于自己产品擅长的方面，而回避了产品中可能存在的差距。在极狐GitLab，我们一致努力避免这个陷阱，我们的透明文化让我们诚实地评估我们的优势和可以做得更好的地方。

GitLab 成熟度框架

GitLab 成熟度框架阐述了构成端到端 DevOps 生命周期的阶段、类别和特征，展示了 GitLab 在哪些方面提供了更好的用户体验，同时也勾勒出了我们计划中的未来路线图。由于这个框架从长期的角度来看待构成不同DevOps阶段和类别的标准/特征，我们用这个框架作为竞争比较的指南。

依据GitLab成熟度框架中，无论是在行业分析师还是GitLab用户中，源代码管理、代码审查和持续集成（CI）这几个类别是名列前茅的。要查看这些比较，请查看我们的 Jenkins CI 页面 ，了解功能、价格和全面的概述。

Jenkins vs. GitLab

保持准确

在确定了评价标准后，如何准确地获取数据是一个重大挑战。我们有一套结构化的信息收集流程，具体如下：

• 网站；
• 文档；
• Demo演示；
• 产品安装和使用；
• 客户反馈。

有时由于多种原因，我们无法为所有供应商的产品完成此过程。原因有几个。首先是供应商的网站或文档中缺乏有效信息。其次，我们可能无法访问他们的产品以验证某些功能。一些供应商不提供免费或易于访问的产品版本，而其他供应商可能明确禁止使用其产品进行比较。

确保准确性的第二个挑战是，供应商并不总是不断推出新的版本和功能，我们的分析可能会略显过时。

每个人都可以做出贡献

我们的开源基因也延伸到了如何管理工具展示页面。我们在内部自由地征求极狐和GitLab公司内部的多个团队意见，更重要的是征求其他厂商团队的意见。任何人，包括其他厂商，都可以使用极狐GitLab创建一个Issue（议题），指出他们希望看到的变化或希望纠正的信息。然后，这个Issue会被分配给相应的极狐（对应极狐GitLab JH的SaaS版本）或者GitLab（对应GitLab CE或EE版本）团队来处理。事实上，最近有一家供应商的产品经理联系我们，希望对他们的比较页面进行修改，我们很高兴地进行了修改。

通过提供评论和反馈的机会，我们希望能促进与那些更了解不同产品的人进行对话，从而用丰富而准确的信息改善工具对比分析。

易于理解

比较页的最后一个挑战是如何使它们易于解释。我们通过两种不同的方式来实现这一点。首先，所有功能层面的对比都列在对比页面中。对于那些对某一特性或能力感兴趣的人来说，他们可以很容易地浏览页面，快速找到他们要找的特性。

有时候，功能细节需要解释，或者可能有一个功能不太符合 "是或不是 "的模式。出于这个原因，我们还在大多数比较页面的开头提供了一个自上而下的分析，提供了一个功能摘要，并提供了额外的背景。这有时意味着一个关键功能可能会在正文文本中丢失，但我们正在尽最大努力保持各供应商的一致性，并快速识别差异。

现在市面上有很多DevOps工具，作为一个以单一应用形式交付的一体化DevOps平台，GitLab可以免除选择、集成、学习和维护成功的DevOps工具链所需的众多工具的痛苦。