企业DevOps:大规模DevOps成功的5个关键

尝过之后DevOps的好处在美国，企业自然会寻求扩大其采用范围。然而，当团队试图扩展DevOps工作时，适用于小规模用例的工具和流程往往不够用。您必须支持所有不同的团队、工具集、应用程序、流程、工作流、发布周期和管道——包括遗留的和遗留的原生云．否则，您可能会以随意的自动化竖井或混合而告终DevOps工具和流程，在质量、安全性、速度以及最终的成功方面都有很大的不同。

成功是至关重要的，因为软件现在几乎是所有业务流程的基础和便利。DevOps以其迭代的、协作的方式进行应用程序开发和交付，处于这个新价值链的中心。大规模实施需要正确的结构、流程和工具。

企业DevOps成功的五个关键原则

作为企业DevOps的先驱和领导者，JFrog知道如何在组织中有效地扩展DevOps。超过5800人客户包括许多世界上最大的企业，在所有垂直领域，我们对大规模DevOps有所了解。我们与这些大型组织合作，因为他们采用了DevOps(现在是云原生现代化)，以频繁和大规模地交付高质量的软件。以下是我们的客户在企业中扩展DevOps时付诸实践的五个关键原则。

1 -集中管理端到端的DevOps流程及其输出

有一个DevOps的平台这使得您不仅可以从一个中心位置管理端到端交付流程，还可以管理这些流程的结果。仔细想想，构建/构件是软件的构建块，是流经CI/CD管道的构件。要大规模启用DevOps，您必须有一个解决方案，允许您从一个解决方案管理端到端自动化工作流和编排，以及这些流程的构建输出。

通过集中管理和统一的体验，您可以获得清晰的可见性和单一的真相来源SDLC还有你所有的软件资产，都集中在一个地方。这应该包括二进制文件、容器映像、CI/CD管道、安全性和遵从性等的管理软件分发到跨越运行时环境、边缘和“事物”的最后一英里部署。

目前,许多CI / CD工具让您管理过程或结果，但不能同时管理两者，也不支持所有类型的二进制文件和技术。你的DevOps平台应该自动化和编排所有的点工具、流程、包类型和环境，支持所有的技术堆栈和构件，这样你就可以轻松地插入现有的工具集，甚至遗留脚本，由一个端到端的DevOps平台来管理。

通过管理两者交付过程,交付资产和输出从一个单一的端到端DevOps解决方案，并且不需要在不同的工具之间进行“上下文切换”，你将能够:

• 确保一致性和可追溯性在软件生命周期中的所有工件中，当它们流经从开发到生产的管道时。这会给你一个真相来源单一用于整个DevOps流程，加快软件交付，提高代码质量、安全性和治理。

• 拥有一个通用的存储库对于不同类型的二进制文件，容器图像，环境，点工具等。

• 集中管理安全性并确保遵从性，包括从代码到产品的所有工具、流程、工件和存储库，包括第三方的。

• 具有充分的可视性在你的整个部门和整个组织。不再有筒仓式流程或雪花式配置。通过在一个平台上的端到端统一体验，您可以共享可见性，并可以在依赖项下载、存储库、部署、构建、管道和发布的任何时候采取行动。

2 -从一开始就安全-内置DevSecOps和“左移”功能

企业DevOps必须在整个软件生命周期(从开发到部署再到生产)中纳入安全性和合规性检查。60%到80%的应用程序代码是由第三方开源组件组成的。使用OSS依赖关系作为我们应用程序的一部分，通过重用生态系统中可用的现有组件，大大加快了开发人员实现价值的时间和生产力。然而，这些依赖项通常包含安全漏洞或，许可合规问题，或其他治理风险。

如今的企业必须应对软件空前的增长。他们正在生产越来越多的工件和应用程序——都使用OSS组件。此外，基于微服务的云原生应用程序的持续采用进一步扩大了攻击面，这是由于无数的连接服务，而且每个容器映像都可以包含数十个带有数百个OSS依赖项的层。

由于越来越快地修补这些漏洞的迫切需求，试图领先于坏人一步，而且每200名开发人员中典型的企业只有一名安全分析师，这种情况变得更加复杂。

试图在软件开发生命周期的末尾附加安全测试会造成瓶颈并降低交付速度。因为安全测试和扫描是一件痛苦的事情，它们往往会被推到流程的末尾，成为瓶颈。

解决方案?

• 安全合规必须是一等公民,使默认情况下，作为您所选择的DevOps平台不可分割的一部分。没有更多的工具/上下文切换，或者记得运行测试或启动扫描。

• 安全必须是普遍的，这意味着它支持所有类型的二进制文件，包括云原生构件，例如容器映像，并且在整个构件生命周期和CI/CD管道中紧密集成。

• 深度递归、扫描从应用层到操作系统层，所有依赖项(包括容器映像)都需要。有些工具可能无法自动扫描和识别到操作系统级别的粒度依赖树，而不需要开发人员进行一些繁重的工作。当心这些类型的解决方案。在默认情况下，您希望确保扫描是自动完成的，一直到核心(特别是随着越来越多的应用程序变得容器化)，每个图像都有多个层。

• 扫描必须是连续的和自动的-在DB级跨所有存储库和生产实例。确保您的扫描不仅仅局限于由管道触发的安全扫描。这是因为许多依赖关系可能已经存在于“系统”中，并且跨现有的应用程序/构建。数据库级别的扫描可以确保如果发现新的漏洞，您会收到警告，并可以对它们进行修补——即使是在处理旧的应用程序或可重用的包时，它们可能不是当前“活动”CI/CD交付管道的一部分。
  
  除了db级的连续扫描之外，您应该(当然)能够触发安全扫描和安全门作为CI/CD自动化的一部分-作为另一个验证阶段。

• 启用“左移位”- - - - - -你的App 保护解决方案必须与您的IDE，这样您就可以在开发应用程序的过程中尽早识别和修补漏洞。越早发现这些漏洞，修复它们的成本就越低——而不是等到代码准备好构建，更不用说发布到生产环境了。

• 建立治理规则对于安全性和合规性策略，可以根据软件开发阶段和公司的情况灵活地调整实施范围和后续行动DevSecOps推广计划。根据您的团队、应用程序、用例、DevSecOps成熟度和风险，您的策略可能或多或少严格。例如，如果识别出某些高度严重的cve，您可以选择简单地向开发人员或安全分析人员发送警报。或者，您可以自动地让构建失败、部署失败或创建发布BOM失败，甚至阻止初始下载和使用具有特定漏洞或许可遵从性问题的某些依赖项。

云原生的未来证明:现代化势在必行

当您现代化您的应用程序以利用现代云原生模式和技术(如Kubernetes)时，请记住您仍然需要能够更新您的遗留应用程序-并且不是所有的应用程序都是容器化的微服务(目前)。

企业DevOps平台应该如此支持原生云和遗留应用程序，这样您就可以管理这两种应用程序的整个生命周期。这包括他们的二进制文件、CI/CD进程、安全扫描等等，而无需切换到单独的工具。

同样的,你的DevOps平台必须是混合和多云的，这样你既可以使用它，也可以使用它来管理跨预置、私有和公共云混合环境的交付管道，多重云，以及边缘基础设施。

4 -管道作为代码

将管道定义为代码的能力提高了开发人员的生产力，并有助于扩展DevOps工作。您可以在源代码控制中存储管道定义，这使得它们可共享(因此您可以与您的团队协作)、可版本化、可重用、可审计和可再现。

这消除了开发人员之间的冗余工作(因此不是每个团队都需要重新发明轮子来创建他们的CI/CD自动化)，并且还允许您在整个组织中标准化和使用经过审查的自动化过程。

此外，它还使您的团队能够持续像产品一样发展你的交付管道在每个后续版本中强化、改进和增强您的过程。

让我们更详细地看看管道即代码的好处和一些最佳实践:

• 跨团队的重用和标准化:“管道即代码”允许您建模和定义构建块，DevOps团队需要在整个组织中标准化他们的工作流和流程。这有两个主要好处:

1. 1. 提高速度和开发人员的生产力由于消除了多余的工作。而不是让每个团队从头开始构建他们的管道，每次都创建他们自己的流程和策略，管道即代码允许您重用和共享自动化构建块——包括他们的对象、流程、秘密、资源、配置、策略、安全测试、条件执行等等。2022世界杯阿根廷预选赛赛程
   2. 改善质量和治理由于能够标准化经过批准的、强化的、在整个组织中一致的过程。这些努力消除了雪花配置、自动化竖井、不同的流程和易出错的脚本，这些脚本可能会引入漂移和质量问题。

• 使用参数在你的管道代码中。请记住，为了允许不同的团队利用相同的管道作为代码，这些构建块应该被参数化，以便每个团队都可以动态地调用他们适当的输入(例如秘密、资源、环境配置参数等……)2022世界杯阿根廷预选赛赛程

• 使用声明式自动化。管道即代码构建块最好是声明性的，这样它们可以更容易地定义和扩展，避免“意大利面条”、容易出错的脚本或繁重的工作。声明式管道也更适合于Kubernetes等原生云环境。

• 启用遗留工作流的现代化。由于大型组织不会从所有的新应用程序开始，并且有很多遗留脚本和技术债务，因此您的DevOps平台应该足够灵活，以使您能够继承遗留的CI/CD技术(例如旧的构建工具)，甚至自定义脚本(例如Perl/Bash自动化)。这些也需要在“管道即代码”脚本中得到支持，使用调用外部系统或自定义代码的标准步骤或集成。通过这种方式，这些遗留脚本可以由现代CI/CD解决方案触发和编排，以实现端到端自动化，直到您有时间重构或现代化它们。

• 平台团队(下文将详细介绍)经常使用管道作为代码作为一种在组织中扩展DevOps采用的方式，并与经过认证的流程、提升门、安全性和遵从性检查等保持一致。

5 -全球化思维，本地化行动，平台团队

系统级的思考是DevOps的关键原则之一。这意味着系统地、全面地思考你的整个DevOps生态系统和软件交付实践——包括你的团队、文化、价值流、流程以及技术和架构选择。

要在企业中扩展DevOps，您需要考虑您的组织范围的过程和工具，同时考虑到灵活性、敏捷性、以及每个团队的特殊需求，以便继续授权开发人员并实现自治。虽然你不希望对每一件事情都有一个“狂野西部”和雪花式的配置/脚本，但当某些团队/应用程序需要特定的工具或流程时，你也不希望限制选择的自由或灵活性。

你的DevOps平台需要让你“放眼全球，立足本地”。换句话说，整合不必以牺牲团队自主性、灵活性或速度为代价。例如，对于某些用例，您应该能够实施不同的安全策略，或者能够集成特定的最佳点工具。

这种方法减少了漂移，并防止你最终得到雪花般的工作流或配置，同时还确保遵从性和灵活性，以支持DevOps生态系统中的任何工具或流程——无论是遗留应用程序交付还是云原生应用程序交付。

这就是DevOps平台团队的用武之地!

应用程序交付是当今组织的关键能力和竞争优势。随着部署频率的扩大和增长，许多企业意识到继续将交付作为针对不同团队的临时/竖井式的不同解决方案来管理是不切实际的。

DevOps平台团队(也称为平台运维或交付服务)负责选择工具和交付基础设施，使所有内部团队都能使用DevOps-as-a-Service共享工具、过程和治理．平台团队为所有团队提供一致的、标准化的流程，以提高速度、生产力、可靠性和TCO。为此，一旦他们选择了他们选择的工具，平台团队通常:

• 利用Pipelines-as-code作为在组织中扩展和加速DevOps采用的一种方式，同时确保治理、遵从性和可审计性。作为这些工作的一部分，他们经常设计用于整个公司的流程和管道。他们带头开发、强化和认证自动化构建块，并将它们提供给团队，以便从中央回购中使用。随着新需求的出现，它们进一步增强了这些过程——这意味着组织可以以一种可伸缩的方式使用不断演进和改进的一致过程——从而简化和加速总体交付。
• 管理一个自助式节点拉取和秘密旋转的目录使开发人员能够以安全的方式提供具有一致配置的环境。
• 允许对“认证”包的共享存储库进行集中访问，供开发人员使用。平台团队通常负责加固和保护OSS依赖项，通过遵从性测试运行它们，并在它们经过审查和遵从后“签字”组织的治理政策．这种模式不是让每个团队都必须自己保护和强化OSS依赖关系，而是消除了重复工作，并支持围绕共享的、安全的工件进行重用和标准化。
• 管理管道和软件分发到最后一英里部署的团队/阶段之间的二进制文件共享以集中的方式-优化整个网络的利用，并确保安全和治理。例如，在具有职责分离需求的组织中，平台团队经常管理“生产就绪”二进制文件的自动认证和转移到只读边缘存储库，这些存储库位于生产附近，只有授权人员可以访问，基础设施节点被映射为仅从这些批准的位置提取部署序列的二进制文件。
• 集中管理RBAC (Access Controls)确保遵从性和可审计性——能够确定所有已批准组件的访问级别，包括存储库、工件、工具、管道流程、批准、环境等等。

看看它的行动!

观看网络研讨会《开发者推动大规模DevOps:成功的5个关键》JFrog的产品管理高级总监Loreli Cadapan提供了JFrog统一的端到端企业DevOps平台，包括通用工件存储库、安全合规扫描用JFrog x光，管道自动化,软件分发特性。