GitOps 如何融入 DevOps 体系

GitOps 以版本化的声明式期望状态与调和机制控制变更。它补充更广泛的 DevOps 运营模型；仅凭 Git 仓库无法解决环境隔离、密钥管理与回滚验证。

随着云原生采用加速，GitOps 等新概念帮助组织更快交付高质量软件。GitOps 运用 DevOps 最佳实践，使团队可通过 Git 命令与生产环境交互。

它强调开发者体验，并通过 Git 与 Flux CD、Argo CD 等持续部署工具实现更高自动化与透明度，减少本可自动化的手工工作。 本文介绍 GitOps

原理、工作方式，以及与 DevOps 的差异。 什么是 GitOps？GitOps 是面向云应用（尤其 Kubernetes 部署）的持续部署方法，强调以开发者熟

悉的 Git 与 CD 工具运营环境。 常见工具除 Git 外还有 Flux CD、Jenkins X、Argo CD、Gitkube、Helm Operato

r、Quay 等。GitOps 本质是以分布式版本控制系统正确实践 Infrastructure as Code（IaC），管理源码、证书与配置文件并支持团队协作。

Git 仓库中包含生产环境基础设施的声明式规格。

采用 Infrastructure as Code（IaC），通过自动化流程使生产环境与仓库定义状态一致。

部署或更新应用时，仅需更新仓库，其余由自动化流程完成。

Git 是 GitOps 中唯一的可信来源。

以 G

it 仓库为核心管理应用基础设

施的不同状态。 Git Ops 是以当前状态与期望状态方法正确实施 IaC。支持推式

与拉式策略。 生产环境的当前状态由 Git 仓库表示。Git 记录应用状态并跟踪每

次变更，便于理解应用健康度。 提交、拉取、PR 等 Git 操作用于修改应用状态。Gi

t 流规范部署、测试与回滚。 变更 Git 状态后，集群状态应与仓库定义一致。不支持手

工部署、随意改集群或在线改配置；任何变更须先提交 Git。 GitOps 将版本控制与

C I/CD 等 DevOps 实践用于自动化基础设施，可借助 Git 与 CI/C

D 复制或回滚环境。GitOps 如何工作？ 核心思路简单：用 IaC 脚本创建、更新

或删除基础设施，可使用 Terraform、Pulumi、YAML 等，将全部基础设施

与应用文件存入 Git 并自动化部署与更新。示例：将 Kubernetes 部署定义提

交 Git 后触发自动化，在集群中 apply 变更。 常见实现为拉式 operato

r 监听期望状态并执行 kubectl apply 扩展 Kubernetes 能力。

推式部署由 Jenkins、CircleCI、Travis CI 等 CI/CD 工具执行。应用源码与部署所需 Kubernetes YAML 位于应用仓库。

更新应用代码会触发构建流水线生成镜像，并更新环境配置仓库中的部署描述符；该仓库更新后再触发部署流水线，向环境提供配置。此方式需向部署环境提供凭证。

自动化开通云基础设施时常用推式策略，可结合云厂商细粒度授权以降低部署权限。

推式 GitOps 中，环境仓库变更触发部署流水线，因此需要监控机制，以便在实际环境与仓库不一致时及时干预。

拉式 GitOps 依赖外部事件（如新代码推送到应用仓库）触发 CI/CD 流水线。

拉式部署需要 operator，比较环境仓库中的期望状态与实际部署状态，如有差异则更新基础设施。也可检查镜像仓库以识别新版本。环境仓库变更时，拉式策略会更新运行环境。

operator 需与目标应用同环境部署，外部服务无需知晓凭证，可结合 RBAC 与身份机制控制谁能部署，兼顾安全。

GitOps 面向云应用（尤其 Kubernetes）的持续部署，强调开发者

熟悉的 Git 与 CD 工具。 DevOps 是一组实践、工具与 理念，自

动化并整合开发与运维流程，聚焦赋能团队、跨团队协作与技术自动化。 GitOp

s 以 Git 为单一可信来源，实现基础设施开通、软件部署与回滚。 DevOp

s 聚焦 CI/CD，不绑定单一工具。 GitOps 常用 Fl ux CD、

Kubernetes、 Argo CD、Jenkins X、Hel m Ope

rator、Pulumi、Quay 等。 DevOps 工具类别包 括代码与制

品仓库、CI/CD、容器管理、基础设施配置与部署工具等。 GitO ps 约束

更强、开放性较低；DevOps 相对灵活开放。 GitOps 强调 正确性；D

evOps 强调自动化与频繁发布。 GitOps 仍处于成熟早期， 但随 Ku

bernetes 应用增长，因其复用开发者熟悉的 Git 而在云社区广受认可。