探索持续提升（Continuous Promotion）如何解决传统 CI/CD 流水线的局限性。
译自 Why CI and CD Need to Go Their Separate Ways，作者 Christian Hernandez。
在不断发展的软件开发领域，持续集成 (CI) 和持续交付 (CD) 一直是高效可靠的应用程序部署的基本方法。
尽管它们已经存在了很长时间，但像 Kubernetes 和 GitOps 这样的现代技术带来了传统 CI/CD 流程 无法解决的复杂性。 随着 Kubernetes 提供异步部署机制，GitOps 提供管理应用程序状态的声明式方法，两者之间出现了差距。
持续推广和相关工具旨在弥合这些差距，在以 GitOps 为中心的 环境中简化 CI/CD 流水线。
CI 和 CD 是软件开发中的基本实践，旨在提高部署应用程序的速度和可靠性。最初，CI/CD 是一个线性过程：构建代码、测试代码，然后将其部署到目标环境。这种方法适用于传统的虚拟机或物理服务器，因为在这些服务器中，部署环境相对静态。
然而，容器和 Kubernetes 的引入极大地改变了这一格局。Kubernetes 提供了一种更加动态的异步部署机制，这与传统 CI/CD 流程的同步性质不匹配。因此，团队开始采用 GitOps 来更好地适应这种新范式，并试图减轻与传统 CI/CD 流程的脱节。
尽管取得了这些进步，但 CI/CD 流程在很大程度上保持不变，导致跨不同环境管理部署的效率低下和复杂性。这种持续的演变凸显了对持续推广等更加集成化的解决方案的需求，以有效地弥合这些差距。
当前的 CI/CD 模型面临着若干挑战，尤其是在 采用 Kubernetes 和 GitOps 的情况下。
问题的症结在于传统 CI/CD 流程的同步性质与 Kubernetes 部署的异步性质之间存在固有的脱节。这种不匹配通常会导致效率低下，因为部署流水线中充斥着自定义脚本和变通方法，以弥合 CI 和 CD 之间的差距。
此外，GitOps 虽然可以有效地管理部署的最后一英里，但无法处理复杂的多环境编排。它只关注最终的部署状态，在跨不同阶段或环境协调部署方面留下了巨大的运营空白。
这导致 CI 流水线过度扩展，并承担了它们从未设计过的角色，例如管理无限期部署和处理复杂的依赖关系。这些挑战凸显了对一种更具凝聚力的方法的需求，这种方法可以与现代技术无缝集成，从而提供更加灵活高效的部署流程。
将 CI/CD 视为一个简单的线性过程的传统观点掩盖了现代软件开发中面临的复杂现实。虽然最初被概念化为一系列步骤——构建、测试和部署——但实际的部署流水线要复杂得多。现代应用程序通常涉及许多相互关联的服务，每个服务都有自己的依赖关系和生命周期。
线性模型难以适应这些复杂性，导致必须管理相互依赖关系和异步流程的网络。此外，微服务架构 的兴起进一步加剧了这种复杂性，因为每个服务都可能有自己的 CI/CD 流水线，并具有不同的需求和触发器。
这种复杂性会导致部署瓶颈、人工干预增加以及难以在不同环境中保持一致性等问题。此外，对持续监控的需求以及处理动态云环境中快速变化的能力，都需要比传统线性方法所能提供的模型更加灵活和自适应的模型。适应这种复杂的现实对于有效的 CI/CD 实施至关重要。
在许多组织中，CI 流水线的功能超出了其预期功能，承担了传统上属于 CD 领域的任务。
CI 的设计目的是自动化构建和测试代码，专注于创建可靠的工件。然而，随着部署环境复杂性的增加，CI 流程通常背负着环境配置、配置管理和部署编排等任务。
这种过度扩展会导致繁琐、低效的持续集成管道，它难以管理现代化动态部署的需求。这种错误使用不仅增加了持续集成管道的复杂性和维护开销，还导致循环时间更长、灵活性降低。解决这个问题需要在持续集成和持续交付之间明确划分职责，利用适当的工具让每个流程专注于其核心目标，而无需不必要的重叠。
持续提升这一概念旨在弥合 CI 和 CD 之间的差距，解决在使用 Kubernetes 和 GitOps 等现代技术时传统 CI/CD 流水线的局限性。
其理念是插入一个中间步骤，专注于根据预定义的规则和条件提升工件。这种方法允许对部署过程进行更精细的控制，确保工件仅在满足特定条件（例如通过某些测试或获得必要的批准）时才会被提升。
通过这样做，持续提升将 CI 和 CD 流程分离，使每个流程都可以专注于其核心职责，而不会过度扩展。这不仅简化了部署流水线，还提高了整个流程的可靠性和效率。持续提升的需求源于现代部署日益增长的复杂性，在这些部署中，传统的 CI/CD 方法难以有效地管理云原生环境的异步和动态特性。
持续提升具有多种优势，可以提高部署流水线的效率和可靠性。
在 CI 和 CD 之间引入系统性步骤可确保只有合格的工件才能通过流水线，从而降低错误部署的风险。这种方法允许实施详细的规则集，其中可以包含成功完成测试、手动批准或合规性检查等条件。因此，持续提升可以更好地控制部署过程，使团队能够自动执行原本需要手动干预的复杂决策过程。
此外，它还减轻了 CI 流水线的负担，这些流水线通常因处理非其设计用途的部署任务而超载。这种关注点分离允许更专注、更高效的 CI 流程，而 CD 可以专注于应用程序的部署和管理。
总的来说，持续提升更符合现代云原生环境的动态特性，有助于实现更顺畅、更可靠的应用程序推出。
Kargo 是一款开源工具，旨在 CI/CD 流水线中实施持续提升的概念。它通过提供结构化的变更提升机制，解决了在 Kubernetes 和 GitOps 环境中部署应用程序相关的复杂性。
Kargo 通过监控工件（例如应用程序映像或配置文件）的变更并应用预定义的提升规则来确定这些工件是否应进入部署的下一阶段来运作。该工具通过引入用于管理提升的声明式框架，有效地弥合了 CI 和 CD 之间的差距，确保只部署经过审查的变更。
Kargo 不会取代现有的 CI 或 CD 工具，而是通过添加一个专注于协调工件提升的中间层来增强它们。通过这样做，它有助于促进更可靠、更高效的部署流程，减少管理复杂部署所需的手动工作量，并更好地适应云原生生态系统的异步特性。
Kargo 通过充当协调 CI/CD 流水线中工件提升的中间层来促进持续提升。它通过持续监控存储库中的变更（例如代码、配置或 Docker 映像的更新）来运作。
根据预定义的规则和条件，Kargo 会评估这些变更是否满足提升条件。此评估会考虑成功测试结果、合规性检查和必要的批准等因素。一旦满足条件，Kargo 就会自动执行提升过程，更新 GitOps 存储库以反映新状态，并通过 Argo CD 等 GitOps 控制器触发部署。
这种方法最大限度地降低了部署未经验证的变更的风险，确保了更高水平的部署可靠性和效率。通过使用 Kargo，团队可以减少手动干预并简化其部署流程，从而使 CI 工具能够专注于构建工件，而 CD 工具则可以管理推出。这种集成使 Kargo 成为现代动态部署环境中的重要组成部分。
您是准备尝试 Kargo 的 GitOps 从业者吗？请访问 Kargo GitHub 页面，开始您的持续提升之旅。已经是 Kargo 用户并希望将其提升到一个新的水平？注册我们的 Kargo Enterprise 早期访问。