GitOps 作为一种新兴的运维实践，由 WeaveWorks 于 2017 年提出，其核心理念是将应用配置、数据库设置、编排参数等以代码形式存储在 Git 仓库中，从而实现应用部署的版本控制、自动化和标准化。
GitOps 部署策略主要分为基于 Push 和基于 Pull 两种方式，前者从开发视角发起更新，后者则利用权限控制保障安全性和合规性，确保集群配置与代码库保持一致。两者的主要区别如下：
基于 Push 的方式
基于 Pull 的方式
1. Push 方式是作为上帝视角来做环境的更新，而 Pull 方式则可以利用权限鉴权等信息做安全性及合规性保障。
2. Push 方式是在代码变更后触发更新，如果有人手动修改了集群中的配置，集群中的配置就会和代码库中的配置有差异；而 Pull 方式实现方式，则是检测集群和代码库中的配置，当发现不一致时，自动/手动触发更新，让环境中使用的配置始终和代码库中的保持一致。
Zadig 关于 GitOps 的思考
Zadig 作为一款开源云原生 DevOps 平台，致力于帮助工程师成为企业创新的核心引擎。Zadig 深度融合 GitOps 的思想，结合 Pull 和 Push 两种方式进行实践，帮助工程师高效输出：
1. 让工程师专注在业务价值创造上，减少其对繁琐部署流程的参与：Webhook 及全自动软件交付流水线能力，让业务代码“所见即所得”的在环境中生效。
2. 降低工程师对服务配置、环境管理的心智负担：服务配置 AsCode，Git 仓库中环境配置变更后自动同步到 Zadig 中，服务配置变更后自动更新环境。
下面具体阐述 Zadig 是如何实践 GitOps 来助力高效交付的。
Zadig 中的 GitOps 实践
Zadig 中的 GitOps 实践是实现高效持续交付的关键策略。通过代码变更、环境配置变更以及服务配置变更都能够触发自动化的部署流程，确保了开发和运维团队的紧密协作与快速响应。
代码变更
在 Zadig 中配置工作流，增加触发器配置后，系统会自动在对应的 Git 仓库中创建 Webhook。当满足条件的事件发生时会自动触发工作流执行，将最新代码变更部署到环境中。
对于不同的环境，在工作流中配置多个 Webhook 触发器，实现多环境的 GitOps。
环境配置变更
1. 从 Git 仓库中导入环境配置（Ingress/ConfigMap/Secret/PVC），导入时开启
自动同步
开关。
2. 当 Git 仓库中配置内容变更后，会自动更新 Zadig 中的环境配置。
服务配置变更
1. 从 Git 仓库同步服务配置。
2. 在服务策略中开启
服务自动更新
开关，当代码库中的服务配置内容有变更时，会自动同步更新 Zadig 中的服务配置，并自动基于新的配置更新环境中的对应服务。
3. 动图演示效果如下：
小结
Zadig 的 GitOps 实践简化了部署流程，提高了部署效率，通过服务配置的及时同步和环境的自动更新，为团队带来了一致性，支持团队快速迭代产品，缩短了从代码到交付的周期，加速了价值验证的过程。
