持续提升是 CI 和 CD 之间的一层，它监控工件的变化并协调它们从开发到生产的路径。
译自 Understanding Continuous Promotion and Where to Start，作者 Christian Hernandez。
持续集成和持续交付 (CI/CD) 长期以来一直是现代软件开发的基石，它无缝地整合代码变更并确保它们在各种环境中快速部署。然而，随着 Kubernetes 和 GitOps 的出现，生态系统不断发展，传统的 CI/CD 机制开始显露出局限性。
持续提升为云原生环境量身定制了一种 CI/CD 的变革性方法。传统的 CI/CD 流程往往难以跟上 Kubernetes 和 GitOps 的动态特性。引入持续提升机制弥合了 CI 和 CD 之间的差距，使工件的提升更加流畅。
传统的 CI/CD 流程以线性工作流为中心——构建代码、运行测试、打包应用程序并将其部署到目标环境。在许多情况下，这些环境是虚拟机 (VM) 或带有预安装依赖项的裸机服务器。这种方法对于单体应用程序来说效果很好，但随着 微服务 和 容器化 的兴起，其局限性开始显现。
容器的引入提供了一种标准化的打包机制，但传统 CI/CD 的同步特性难以与 Kubernetes 的异步、声明式特性相一致。
因此，组织经常发现自己将 Kubernetes 嫁接到现有的工作流程中，导致效率低下和操作摩擦。尽管 GitOps 的出现简化了最后一公里的部署，但核心 CI/CD 流程在很大程度上保持不变。这种不和谐突出了对一种能够处理现代云原生环境复杂性的演进方法的需求。
Kubernetes 和容器化彻底改变了软件部署的格局。容器提供了一个一致且可移植的环境，简化了应用程序的打包和分发。Kubernetes 以其强大的编排能力，已成为大规模管理容器化应用程序的事实标准。
然而，这种转变给传统的 CI/CD 管道带来了新的挑战。传统 CI/CD 流程的同步、线性特性难以跟上 Kubernetes 的声明式、异步操作。这往往会导致不匹配，即 Kubernetes 的动态环境管理与传统 CI/CD 的严格步骤发生冲突。
此外，管理多个微服务（每个微服务都有自己的生命周期）带来了额外的复杂性。随着团队采用 Kubernetes，他们经常不得不创建自定义脚本以弥合这些差距，导致工作流程支离破碎且容易出错。这突出了在云原生生态系统中对更集成和自适应的 CI/CD 方法的必要性。
尽管取得了进步，但传统的 CI/CD 流程和 Kubernetes 操作往往不一致。同时，在 GitOps 框架中，有一种趋势是将 CI 的作用扩展到其预期范围之外。
我们在之前的文章 “为什么 CI 和 CD 需要分道扬镳” 中仔细研究了这些问题。那么我们如何解决这些问题并最终取得胜利呢？
持续提升是一种创新方法，旨在增强云原生环境中的传统 CI/CD 管道。与将 CI 和 CD 视为独立流程的传统方法不同，持续提升通过一个连贯的框架将它们整合在一起。
它利用 CI 和 CD 的优势，确保工件提升是自动化的，并与组织策略保持一致。持续提升充当一个中间层，监控工件的变化并协调它们从开发到生产的各个阶段的进展。
它使用规则集和持续验证机制，确保只有经过验证的更新才能提升，从而降低了失败的风险。这种方法不仅简化了部署过程，而且还增强了可见性和控制力，使管理复杂的微服务架构变得更加容易。因此，持续提升代表了 CI/CD 范式的一次重大演变，使其更贴近现代云原生应用程序的需求。
听起来不错，但从哪里开始呢？为了让您的 CI/CD 流程充分利用 Kubernetes 和 GitOps 的优势，持续提升需要与 CI 和 GitOps/CD 流程“原生对话”。
一个成功的持续提升工具或流程必须包含以下内容：
工件的协调循环
协调循环流程持续监控工件存储库，以发现对部署相关工件的任何更改。在 Kubernetes 和 GitOps 的情况下，这可以是 Helm 存储库、git 存储库和/或容器镜像存储库。
基于策略的检索工作流
将基于策略的检索工作流整合到监控的存储库中。持续提升工具应该考虑到 CI 流程一直在进行，并非对这些存储库的每次更新都需要部署。通过基于策略的检索工作流，用户可以围绕部署构建业务逻辑，并且只检索需要部署的工件。
理解工件和部署之间的关联
它理解相关工件之间的关系，以及它们应该何时/如何一起部署。持续提升不需要存储工件，而是将工件保留在它们想要的位置，持续提升流程跟踪这些工件的元数据。通过使用关于工件存储位置和哪些版本感兴趣的知识，创建了一种“元”工件，作为单个可部署单元。
理解工件和目标阶段之间的关联
它理解工件与它们需要处于哪个阶段之间的关系（通常组织将这些阶段视为“环境”）。持续提升流程不会直接参与 GitOps/CD；相反，它与真相来源（git）交互，并充当协调器，知道何时、何地以及如何促进提升流程。
这保持了 CI（主要产生工件）和 GitOps/CD（专注于部署这些工件）的自然分离。这将重点从基于“环境”的提升转移到基于目的的提升。工件的目的才是决定因素。
成功验证机制
它使用从现有指标提供者收集的数据来验证部署后工件的提升。成功的持续提升工作流需要能够与现有指标提供者集成，以确定提升流程的整体健康状况。
Kubernetes 对象健康检查只是应用程序堆栈更大图景中的一小部分，因此持续提升工作流必须考虑应用程序的整体健康状况及其行为方式。与指标提供者和渐进式交付工具携手合作，持续提升完美地融入现有工作流，为您的云原生应用程序交付流程的端到端过程提供最终的可视性。
我们对这些挑战的解决方案称为 Kargo，这是一个开源工具，旨在在 CI/CD 管道中实现持续提升。它通过提供一种结构化的机制来促进更改，解决了与在 Kubernetes 和 GitOps 环境中部署应用程序相关的复杂性。
Kargo 不会取代现有的 CI 或 CD 工具，而是通过添加一个中间层来增强它们，该中间层专注于协调工件的提升。通过这样做，它有助于促进更可靠、更高效的部署流程，减少管理复杂部署所需的人工工作量，并更好地与云原生生态系统的异步特性保持一致。