本文档介绍了一个框架，该框架可在使用 Google Kubernetes Engine 的多团队软件交付平台上实现现代持续集成/持续交付 (CI/CD) 流程。
然后，您可以迭代该平台，以进一步改进开发和运营的性能，包括发布速度、平台可靠性和故障恢复时间。
本文档是以下系列文章中的一篇：
借助 GKE 实现现代 CI/CD：软件交付框架（本文档）
本文档面向企业架构师和应用开发者，以及 IT 安全、DevOps 和站点可靠性工程团队。拥有一些自动化部署工具和流程的相关经验对于理解本文档中的概念很有用。
现代 CI/CD 案例
CI/CD 是一种软件开发方法，可让您通过多种工具和可重复流程自动执行软件开发的构建、测试和部署阶段。
除了 CI/CD 自动化之外，Kubernetes 和容器还让企业在开发和部署的速度方面实现了前所未有的改进。然而，即使 Kubernetes 和容器采用率不断增加，许多组织也并未完全意识到发布速度、稳定性和运营效率所带来的优势，因为其 CI/CD 实践并未充分利用 Kubernetes 或地址运营和安全问题。
真正的现代化 CI/CD 方法需要的不仅仅是实现自动化。若要全面实现速度和安全性方面的改进，并利用 Kubernetes 和容器的强大功能，您需要简化应用的初始配置、CI/CD 实践和运营过程。
在实现中使用 GKE 平台提供的一致基础架构、统一 CI/CD 方法以及最佳做法，您的组织可获享开发和运营方面的以下优势：
缩短更改前的准备时间。
让运营团队和安全团队在整个平台中创建和更新预配应用和预配政策的最佳做法。
通过为团队提供功能完备且可部署的入门级项目（其中内建了您的组织的最佳实践）来简化应用的初始配置。
缩短恢复服务所需的时间。
使用 GitOps 以声明方式管理所有配置，以简化审核、回滚和检查。
对整个组织内的部署和监控方法进行标准化，可以缩短识别服务影响问题的贡献因素所需的时间。
增加部署频率。
确保应用开发者可以在自己的开发沙盒（或着陆区）中独立地进行迭代，而不会相互干扰。
使用 GitOps 进行部署、改进版本管理和更改跟踪。
实施标准以便服务团队能够频繁部署。
创建渐进式发布流程，以便在预生产环境中一致地进行部署，使开发者能够放心地将更改部署到生产环境。
如需了解如何借助 GKE 和 CI/CD 实现这些优势和概念，请参阅本系列中的其他文档：
评估现代方法的就绪情况
在借助 GKE 实现现代 CI/CD 工具和流程之前，您需要评估您的组织和团队是否已准备好采用新平台。
单位特征
采用现代化平台需要业务主管和技术团队提供以下支持：
领导赞助商。通常情况下，采用软件交付平台需要多个跨职能团队投入大量精力。此过程通常导致角色和责任以及软件开发做法更改。要成功采用这些工具和技术，您需要获得领导团队中的一位或多位成员的大力支持。最有效的领导赞助商是指将这些更改视为持续改进过程，并希望增强其团队而不是管理他们的那些人员。
技术和业务策略的一致性。我们建议您的业务团队和技术团队将 DevOps 研究和评估 (DORA) 定义的四种主要软件交付方式保持一致：更改前的准备时间、部署频率、服务恢复时间以及更改失败率。这些方式保持一致可确定您的业务团队和技术团队面向共同的目标，使他们能够综合计算投资回报率、调整变化率，以及修改投资水平。
资源。为了取得成功，开发现代 CI/CD 做法和构建工具链的团队需具备必要的资源：时间、人员和基础架构。这些团队需要时间来尝试和选择最佳处理过程和工具。理想情况下，这些团队代表软件交付过程中的许多不同功能，并且可以从组织中提取其他资源。最后，团队需要能够预配基础架构，包括云端资源和软件工具。
开放采用新工具。 新工具和流程通常提供现代 CI/CD 工具和技术。团队需要体验这些流程和工具，并开放性采用这些流程和工具。需要提供反馈环，以便平台团队能够听取使用该平台的应用、运营和安全团队的反馈。
文化就绪性。为了借助 GKE 成功部署和采用现代 CI/CD 系统，开发系统的组织和技术团队需要做好准备以便更改他们的运营方式和协同工作的方式。例如，开发和运营团队需要有意愿花费更多时间来承担安全责任，安全团队和运营团队需要有意愿简化变更审批流程。
技术能力
如需采用现代 CI/CD 方法，您的团队在技术上必须满足以下条件：
拥有容器使用经验。 采用现代 CI/CD 方法的团队需要具备容器的一些使用经验。理想情况下，此经验包括用于构建容器映像以及组合容器来构建大型系统的开发技术。
持续集成策略。团队需要一些使用 CI 工具（例如 Jenkins、TeamCity、Bamboo 和 CircleCI）和执行一些持续集成和自动测试方面的经验。我们建议组织计划进一步增强这些流程。
部署自动化。 团队需要一些部署自动化使用经验。自动部署工具示例包括基本的 Shell 脚本、Terraform、Chef 或 Puppet。对自动部署工具和流程进行基本了解对于部署和自动执行部署至关重要。
面向服务的架构。虽然这不是采用现代 CI/CD 流程的前提条件，但如果组织想借助 GKE 采用现代 CI/CD 工具和技术，采用更模块化和面向服务的架构必须是其长期目标。事实证明，基于服务的架构可以提高转化速度和可靠性。
现代源代码控制。借助 Git 等现代源代码控制工具，团队可以构建主干开发、功能分支和合并请求等工作流。
利用 GKE 设计现代 CI/CD
本部分介绍了软件交付平台及其组成部分。若要提高软件交付的性能，您需要实施 CI/CD 和其他技术最佳做法，助力团队快速发布并高效工作。
本部分还将介绍支持软件交付生命周期所需的基础架构，以及如何使用 GKE 持续管理该基础架构。最后，本部分提供了一个软件交付工作流示例，并展示了入门代码库如何简化最佳做法的初始配置和实现。对以下设计注意事项进行审查：
软件交付平台。构成高转化率、高可靠性应用发布流程基础的框架和技术功能。
平台基础架构。构建平台和运行应用所需的基础架构组件和管理注意事项。
软件交付工作流。团队如何展开协作以更高效地构建、测试和部署代码。
代码库。用于执行多种功能的代码库，这些功能包括存储实际业务逻辑、应用专用配置以及构建基础架构的代码。这些代码库也可能是入门代码库，可帮助您采用最佳做法并有助于维护自动化流程之间的一致性。
应用着陆区。逻辑实体，允许开发者使用您实施的标准，自主部署并对自己的应用进行迭代。
操作模型。 用于管理基础架构和构成该平台的应用的技术工具、流程和方法。
治理。 维护和管理软件交付平台所需的流程和注意事项。
软件交付平台
软件交付平台整合了工具并简化了构建、交付、部署和运行应用所需的流程。
维护应用的配置、稳定性、正常运行时间和规模的职责因运营商、安全团队和开发者团队而异，但所有组成部分和团队都需要协同工作，来加快发布速度。虽然本文档介绍了改进源控制管理和应用可观测性的方法，但主要讨论持续集成 (CI)、持续交付 (CD) 和配置管理。
如需构建完整的软件交付平台，您需要下图中的每个组成部分：
其中的每个组件都向系统中运行的系统和应用提供功能。
基础架构监控。 预配时所需的基本监控层级，以验证 Google Kubernetes Engine (GKE) 集群、虚拟机 (VM) 实例和应用正常工作所需的其他基础架构是否正常运行。
容器编排。协调基于容器的应用的部署和操作的平台。Kubernetes、GKE 或 GKE Enterprise 的容器编排平台示例。
Container Registr。容器映像的存储和访问权限控制机制。
CI。在部署之前将自动任务应用到应用的过程。CI 任务通常包括构建、打包和测试。任务类型因应用和组织而异。
CD。高度自动化且高频应用的部署流程。示例方法包括手动审批、Canary 部署、蓝绿部署或滚动部署。
政策。 由运营团队和安全团队定义并由平台持续应用和强制执行的安全和基础架构配置政策。
源代码管理。例如，代码、配置文件和政策定义的由版本控制的存储。在现代 CI/CD 系统中，源代码管理通常是 Git。
配置管理。用于存储和应用不同环境的应用配置的系统。
应用可观测性。开发者、运营商和安全团队的应用级日志记录、监控、提醒和跟踪，用于排查和验证应用能否正常运行。
平台基础架构
如需构建可伸缩的软件交付平台，您需要用于开发的 Kubernetes 集群、预生产环境和多个生产集群。集群可以提供许多不同的功能：
开发。在这些集群中，开发者会对其应用执行临时部署以进行测试和实验。
应用环境。
预生产。对于工作流中的每个预生产环境，您都应该有一个 Kubernetes 集群来托管您的应用。这些集群应与生产集群相似，因此您可以减少或消除环境之间的差异，从而提升部署成功率。
生产。 这些集群用于运行您的生产工作负载。您应该使用多个分布在不同地理位置的集群。这样做可以提高基础架构故障的可靠性，简化第 2 天操作问题，如集群升级和扩缩。
下图展示了大致的基础架构：
在此架构中，您可以通过 Config Sync 管理每种环境的集群。一致的集群配置至关重要，因为它可以使开发者、运维和安全团队相信预生产和生产环境以类似方式运行。您可以使用 Config Sync 在集群舰队中存储和应用通用配置。集群配置标准化、可审核且可扩缩后，您可以专注于软件交付工作流以及新手入门和部署应用。
您可以通过应用的 CI/CD 流水线来管理对开发、预演和生产集群的部署。源代码控制管理充当应用代码和配置的协调点。应用的 CI/CD 流水线和容器映像与应用环境隔离。您可以使用入门代码库和自动化工具初始化应用和配置代码库。例如，您可以使用 Cloud Build 来运行 Terraform，以自动完成新应用的初始配置并进行初始化。
将应用部署到它们各自在每个集群上的着陆区，以便通过网络和身份隔离应用。您可以使用 Config Sync 跨各种环境初始化应用着陆区，并使用 Anthos Service Mesh 或多集群 Ingress 通过创建一个跨多个集群的网状网络使生产集群看起来像一个集群。
软件交付工作流
软件交付平台的核心组件是 CI/CD 系统。当平台构建器开始定义 CI/CD 过程时，他们需要确保每个组件都会生成或使用符合标准化接口的工件。当市场上有更好的实现方案时，使用标准化接口会更容易更换组件。
为容器化应用创建平台时，您可以使在组件之间使用三种标准化接口：Git 代码库、Docker 映像和 Kubernetes 清单。这些接口允许您创建一个包含开发、构建和发布工作流的可重用且灵活的 CI/CD 流水线，如下图所示：
此工作流的工作原理如下：
开发者将其应用代码提交到代码库。
CI 系统会测试代码，创建 Docker 映像工件，并将该工件存储在注册表中。
准备好部署工件之后，对工件的引用将添加到应用配置中。
该应用配置被渲染为 Kubernetes 可读格式，并存储在代码库中。更新此代码库将触发一个部署流水线，该流水线会在集成开发环境中部署工件。
完成集成式开发环境中的测试后，运营商会将部署提升到预生产环境中。
确保应用在预生产环境中按预期工作后，运营商会在部署流水线中获得批准，并将版本提升到生产环境中。
当运营商更改基本配置时，这些更改将应用于整个组织。当运营商提交对其代码库的更改时，可以自动触发应用配置更新（和后续部署）。或者，开发者下次部署更改时就能获取运营商的更改。
同时，安全工程师可以实施和调整定义可部署哪些内容的政策，然后将这些政策提交到其政策代码库中。
借助 GitOps 方法，您可以要求采用声明式方式以对应用和集群进行任何更改。使用此方法，所有变更都要先经过审核和审批，然后才能实施。在此声明式模型中，您将配置文件存储在 Git 代码库中。通过该代码库，您可以维护更改日志，回滚失败的部署，并查看提出更改的潜在影响。
在相关联的参考架构中，使用 kustomize 来控制组织中的应用配置。借助 kustomize 工具，运营商可以创建所谓的应用配置基础，您的开发团队可以对其进行调整，而无需在此基础上添加或更改任何代码。通过定义基本配置，平台团队可以为组织创建最佳做法并对其进行迭代。运营商和开发者可以独立对其部署进行迭代，而开发者可以应用由运营商设置的最佳做法。如果运营商需要为组织实施新的最佳做法，则在此基础上进行更改，并且此更改会自动应用到开发者的下一个部署中。
代码库
源代码库位于 CI/CD 系统的核心。运维人员、开发者和安全工程师都有自己的代码库，将更改传播到平台中。将 Git 代码库作为系统中所有更改的基础，可享有多项便利：
内置可审核性。提交包含何人何时因何更改了系统的信息。
简化回滚过程。Git 的还原功能可让您回滚到系统以前的状态。
版本控制。您可以标记 Git 提交内容，使其表示系统状态的版本。
事务。您必须先明确解决状态冲突并进行审核，然后才能将更改集成到状态中。
下图显示了各个团队与集中式代码库就所有变更内容进行交互的情况：
以下各部分介绍了运营商、开发者和安全工程师如何在现代 CI/CD 系统中采用 Git 代码库。
运营商代码库
运营商管理的代码库包含 CI/CD 和应用配置方面的最佳做法，以帮助您的团队对应用进行初始配置，同时从头开始应用组织的最佳做法。借助管理代码库的运营商，开发者可以利用对组织最佳做法的任何更新，同时将对工作流造成的干扰减至最小。
运营商可以将组织的最佳做法编码到两个代码库中。 第一个代码库是运营商维护共享 CI/CD 流水线最佳做法的地方。在此代码库中，运营商为开发者提供了一个可用于构建流水线的预定义任务库。开发者的应用代码库会自动继承这些任务及其内的逻辑；无需手动复制这些任务。以下是您可以在整个组织中实现标准化的任务示例：
工件构建和存储
各种语言的测试方法
部署步骤
政策检查
安全扫描
运营商维护的第二个代码库存储了配置应用的最佳做法。在 GKE 环境中，最佳做法包含在 Kubernetes 资源模型中管理声明式清单的方法。这些清单描述了应用的预期状态。运营商可以为不同类型的应用创建基本配置，从而根据组织的最佳做法为开发者提供用于部署应用的精简路径。
应用代码库
应用代码库存储应用的业务逻辑以及应用正常运行所需的任何专业配置。
当运营商以编码化的方式创建和维护最佳做法时，开发者可以使用这些最佳做法。为此，开发者要引用 CI/CD 任务以及运营商在自己的代码库中创建的应用库。开发者做出更改后，他们可以通过添加特定于环境的配置（例如数据库网址或资源标签和注释）来进一步自定义应用的部署。
您可以存储在应用代码库中的工件示例包括：
应用源代码
它是一个
Dockerfile，描述如何构建和运行应用CI/CD 流水线定义
对运营商创建的应用配置库进行扩展或修改
基础架构即代码库
基础架构即代码库存储用于构建运行应用所需的基础架构的代码。基础架构可能包括 GKE 等网络和容器编排平台。通常，基础架构管理员拥有这些代码库。运营商可以更新它们以实施最佳做法。
您可以存储在应用代码库中的工件示例包括：
- 表示基础架构对象的声明式语言代码（Terraform、Pulumi）。
对声明式 API 定义进行补充的 Shell 或 Python 脚本。
对基础架构团队创建的基础架构基础模板进行扩展或修改。
配置和政策代码库
确保平台的安全增强且一致是运营和安全工程师的首要任务。
配置
通过集中配置，您可以在整个系统中传播配置更改。您可以集中管理的一些常见配置项包括：
Kubernetes 命名空间
配额
基于角色的访问权限控制 (RBAC)
网络政策
您应该始终在整个集群中强制执行这些类型的配置，这样应用团队就不会误用或滥用基础架构。使用 Git 代码库存储配置可以增强通过 GitOps 等方法审核和部署配置等过程。Config Sync 等工具可以简化在基础设施中统一应用配置的过程。
政策
由于开发者可以扩展运营商创建的基本配置，因此您需要一种方法来限制组成平台的集群中所创建的资源。在某些情况下，您可以创建政策，让开发者仅在资源满足特定要求时才创建这些资源，例如创建无法配置为实现外部负载均衡配置的 Kubernetes Service 对象。
在关联的参考架构中，您可以使用 Policy Controller 来强制实施政策。
入门代码库
入门代码库有助于在平台上采用 CI/CD、基础架构和开发最佳做法。入门代码库可以大大降低采用最佳做法方面的费用。最佳做法进而有助于提升功能速度、可靠性和团队工作效率。在关联的参考架构中，存在多种适用于 CI、CD、Kubernetes 配置、Go、Java 和 Python 入门级应用和基础架构的入门代码库。
持续集成
在 CI 中，组织通常拥有一组应用于应用的标准任务。例如，在参考实现中，基础 CI 阶段集如下：编译代码和构建容器映像。由于这些阶段在入门代码库中定义，因此它们在整个平台中进行统一应用。各个应用团队都可以添加其他步骤。
持续交付
与 CI 类似，CD 过程通常都有一组标准步骤，用于通过开发环境、预生产环境和生产环境部署应用。无论使用哪种部署方法，入门代码库都可让平台团队跨应用和环境统一应用这些方法。在参考实现中，部署过程包括跨多个集群发布开发、预生产部署、生产部署，以及使用 Cloud Deploy 手动批准生产部署。
应用配置
如要使软件交付平台生效，您需要使用相同且一致的方法来应用配置。通过使用 kustomize 等工具和 Kubernetes 配置的入门代码库，平台可为应用配置提供一致的基础。例如，在参考实现中，kustomize 基础配置会使用一组已知良好的配置基本集来初始化应用环境代码库。然后，各个应用团队可以根据需要调整配置。
入门版应用
入门版应用有助于减少采用最佳做法（例如可观测性）和容器最佳做法的相关开销。
可观测性。为了高效地运行应用并确保可靠性，应用需要考虑日志记录、指标和跟踪。入门应用可帮助团队构建可提高可观测性的框架和策略。
容器最佳做法。构建容器化应用时，您应该构建小型、干净的容器映像。容器的最佳做法包括将单个应用打包到映像中，从映像中移除不必要的工具，以及主动尝试从最小的基础映像生成小映像。如需了解详情，请参阅构建容器的最佳做法。
参考架构提供基本 Go 应用、基本 Java 应用和基本 Python 应用作为起点。您应该添加根据团队开发的语言、技术栈和应用类型而自定义的入门级应用。
基础架构入门代码库
基础架构入门代码库提供用于创建不同基础架构组件所需的预先编写代码。这些代码库使用由基础架构团队决定的标准模板和模块。
例如，在参考实现中，platform-template 包含用于构建 Google Cloud 项目、虚拟私有云和 GKE 集群的起始代码。基础架构团队通常使用此模板管理供多个应用团队用作共享资源的基础架构。同样，infra-template 包含应用可能需要的基本入门基础架构代码，例如 Cloud Storage 或 Spanner 数据库。应用团队通常使用此模板管理其应用的基础架构。
共享模板代码库
共享模板代码库提供组织中任何人都可以重复使用的标准任务模板。例如，基础架构即代码模块（如 Terraform 模块），可用于创建网络和计算等基础架构资源。
应用着陆区
跨集群使用共享 CI/CD、共享应用配置、一致的政策和配置时，您可以将这些功能结合在一起以创建应用着陆区。
着陆区是一个锁定逻辑实体，可让开发者在其应用中部署并进行迭代。应用着陆区使用您设置的标准，以便开发者可以独立工作。对于每个应用，您需要在每个环境的每个集群中创建一个 Kubernetes 命名空间（例如用于生产、开发或预演环境）。这种一致性有助于运营商随时间变化来调试和维护环境。
下图说明了着陆区的概念：
操作模型
当您采用现代 CI/CD 运营软件交付平台时，保持环境、基础架构和流程的一致性和最新版本非常重要。因此，您需要仔细规划和选择平台的运行模式。您可以从多种模型中进行选择，例如集群即服务、蓝图或多租户基础架构。
由于维护一致的基础架构、限制扩张以及让团队可以专注于应用交付非常重要，我们建议您部署多租户基础架构。在多租户基础架构中部署应用时，应用团队无需管理基础架构，运营团队和安全团队可以专注于基础架构的一致性。
多租户基础架构的注意事项
构建多租户软件交付平台时，请考虑在该平台中构建以下几项：
工作负载隔离。应用着陆区的概念是提供一个隔离工作负载的框架。着陆区是命名空间、网络政策和 RBAC 的组合。所有这些政策都应通过 Config Sync 进行集中管理和应用。
租户使用情况监控。 如需获取集群中各个命名空间和标签的费用明细，您可以使用 GKE 用量计量。GKE 用量计量会跟踪集群工作负载的资源请求和资源用量相关信息，您可以按命名空间和标签进一步过滤这些信息。在多租户集群上启用 GKE 用量计量功能时，资源用量记录将会写入 BigQuery 表格中。您可以将租户特定的指标导出到相应租户项目中的 BigQuery 数据集，以便审核人员对这些指标进行分析，进而确定费用明细。
资源配额。为确保共享集群的所有租户都拥有对集群资源的公平访问权限，您需要实施资源配额。您可以根据每个租户部署的 Pod 数量以及每个 Pod 所需的内存量和 CPU 数量，为每个命名空间创建资源配额。
每个环境有多个集群。 为了提高应用和平台可靠性，您应该为每个预生产环境和生产环境使用多个集群。如果有多个集群可用，您可以将应用分别发布到集群，以进行其他级别的 Canary 验证。此外，设置多个集群有助于缓解与集群管理和升级生命周期相关的问题。
特定于租户的日志记录和监控。如要调查其应用的操作，租户需要具备日志和指标的访问权限。在多租户环境中，日志记录和监控应针对特定应用。对于指标和监控，您可以为每个命名空间使用 Google Cloud Managed Service for Prometheus 和 Grafana。对于日志，您需要创建接收器才能将日志条目导出到 BigQuery 数据集，然后按租户命名空间过滤数据集。然后，租户可以访问 BigQuery 中导出的数据。
如需详细了解多租户基础架构，请参阅企业多租户的最佳做法。
隔离边界
软件交付平台由多个团队构建和使用，因此在平台的不同组件之间设置适当的隔离边界非常重要。隔离边界通过提供以下特质来帮助构建强大的平台：
分离责任。每个团队在其隔离边界内管理资源，而不必担心其余资源。例如，基础架构团队仅负责维护 GKE 集群。运营商或开发者仅负责维护 CI/CD 流水线和应用代码。
精细的访问权限控制。如果资源按隔离边界隔离，请使用精细的访问权限控制来限制访问权限。
减少受影响的区域。您可以单独更改某个组件，而不会影响其他组件。
减少人工错误。由于采用精细的访问权限控制，因此您可以避免从开发环境意外部署到生产集群等人工错误。
这些隔离边界可以存在于不同应用之间、基础架构和应用之间，甚至存在于应用的不同环境之间。
治理
软件交付平台和现代 CI/CD 系统的主要目标是提高整体软件交付流程的效率。就平台管理而言，您需要考虑两个主要事项：应用初始配置，通常属于治理类别；以及平台的持续开发和维护（即将平台视为产品）。
应用初始配置和管理
采用现代 CI/CD 方法和工具的目标是简化新服务的发布流程和初始配置。对新应用的初始配置应该是一个简单的流程，您可以在运营团队和安全团队投入极少的情况下执行该流程。这并不意味着运营和安全团队不参与其中，但从部署和安全角度来看，初始输入会自动通过预配过程进行处理。初始配置应用后，运营和安全团队会通过合并请求、政策更新和最佳做法的实施自然地纳入到发布流程中。
建议创建一些自动化功能来完成新应用的初始配置。这可能包括创建代码库、CI/CD 流水线、着陆区和应用所需的任何基础架构。通过自动化，可将开发团队与组织中其他团队的复杂依赖项分离开来，为开发者提供自助管理应用的自主权。这样，开发者可以非常快速地迭代应用代码，而无需将时间浪费在除编写代码外的其他任务上。自动化应使开发者能够在开发环境中运行应用。若要让应用进入更高的环境，其他团队应参与其中，并遵循审核流程。
在相关联的参考架构中，这种自动化被称为应用工厂。
平台即产品
CI/CD 工作流是一种软件产品，但产品的开发、运营和安全团队的用户除外。考虑到这一点，该平台需要相同的软件开发角色和流程，例如产品所有者、营销（面向内部）、用户反馈循环和功能开发周期。
使用 GKE 部署 CI/CD
当您开始采用 GKE 将现代 CI/CD 部署到组织时，选择最佳的试用应用至关重要。本部分将讨论开发、运营和安全团队在工作中考虑其他因素。
选择试用应用
选择第一个要迁移到该平台的应用并非易事。理想的试运行是处理数据或处理请求但不存储数据的服务，例如缓存层、网络前端或基于事件的处理应用。通常情况下，这些应用更适合防范少量停机时间，以及在部署和配置管理技术时可能发生的部署错误。随着各个团队获取更多的 CI/CD 经验，并开始体验可靠性和速度优势，您可以开始将核心服务迁移至软件交付平台。
开发者注意事项
当您处于现代 CI/CD 开发过程时，功能、更改和部署可以更频繁地执行，并以异步方式进行。 开发团队需要了解变更如何影响下游或依赖系统以及如何测试这些变更。开发、运营和安全团队之间的通信路径必须流畅。为应用和不同服务相互通信的数据约定，制定更好的版本控制做法是一种很好的实践。除了改善通信方法和版本控制之外，以小块方式实现功能并利用功能分支和标志可以改进测试和发布功能的方式。
运营商注意事项
使用软件交付平台时，运营团队需要的工作方式更接近开发团队。他们构建的并非面向外部的功能，而是内部工具和程序，有助于加快面向外部的应用的开发、部署和运营。平台工具由其自己的团队以及开发和安全团队使用。运营商应该构建工具以帮助发布新版应用，并在应用错误或部署失败时回滚这些应用。运营商还应特别注重构建监控和提醒系统，以便主动检测故障并发出提醒。
安全团队注意事项
安全团队应该致力于保护自己与运营团队和开发团队之间的共同责任。这种模式通常称为安全性方面的左移，其中信息安全 (InfoSec) 是开发过程的早期阶段，开发者可使用预先批准的工具，而安全测试是自动进行的。除了这些方法之外，您还可以使用 Policy Controller 以编程方式定义和实施安全政策。通过结合使用各种技术和工具，您可以更加主动地实施安全措施。