企业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的创建失败，甚至阻止具有特定漏洞或许可遵从性问题的某些依赖项的初始下载和使用。

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

当您对应用程序进行现代化以利用现代云原生模式和技术(如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即服务共享的工具、过程和治理．平台团队为所有团队提供一致的、标准化的过程，以提高速度、生产力、可靠性和TCO。为此，一旦他们选择了他们所选择的工具，平台团队通常:

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

看看它在行动!

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