GitOps 是 DevOps 文化的一种工程实践，它重新定义了云原生场景下的持续交付模型。GitOps 下的整个运维体系使用声明式描述，并使用 Git 类似的版本控制系统对基础设施、应用配置等进行跟踪管理，系统任何变更在 Git 版本的控制下更加便捷地进行跟踪。
GitOps 以目标为导向，使用 Git 来维护系统的期望状态，结合 CI/CD 流程中的工具，如 Helm、ArgoCD 等，提高了生产力、安全性和合规性，以及升应用交付的效率和质量保证。
什么是 GitOps
GitOps = IaC + Git+ CI/CD，即基于 IaC 版本化 CI/CD，它的核心是使用 Git 仓库来管理基础设施和应用的配置，并且以 Git 仓库作为基础设置和应用的单一事实来源。GitoOps 重新定义了云原生场景下的 CI/CD 流程。 开发、运维团队以 Git 版本控制，作为中心不可变状态声明，结合 CI/CD 流程中代码审查、自动测试和交付部署，从而实现云原生场景下运维体系的最佳实践。
GitOps 的设计理念
GitOps 本质上 DevOps 文化中的工程实践，而非某项具体的技术或项目，结合当今流行的使用形式，可将 GitOps 系统简单地理解为以下几大特点：
- 代码化描述基础设施和应用的部署状态
对于应用的基础设置资源、应用配置和状态的维护，原则都是应是使用代码化的方式进行声明式描述。只有将各类手动配置的工作代码化，我们才能使用 Git 仓库的形式来管理基础设施和应用的部署。
对大规模应用管理的运维效率和可维护性的关键基础是 IaC （Infrastructure as Code），基础设置无法进行 IaC，GitOps 也就无从谈起。
- 使用 Git 的语义来管理代码化后的配置代码
基础设施代码化后面临着管理问题，而 GitOps 顾名思义，采用 Git 语义来管理这部分代码，主要有：
- IaC 代码存储于 Git 仓库中
- 基于分支模式来管理代码版本
- 开发人员使用 Pull Request 来提交 IaC 变更
更高级的管理人员，对这部分变更进行 Code Review，合规之后进行 Merge 到主版本，进而应用到线上环境， 而当线上环境出现问题时，再基于 Git 历史进行回退。
- 具备将配置代码进行自动化部署的能力
我们还必须要有相应的能力将 IaC 代码自动化部署于各种真实的线上环境，当 Git 仓库中声明的期望状态发生变更时，可以立刻自动化应用到系统中，使其当前环境与 Git 仓库中 Iac 所描述的状态一致。
- 应用状态偏离修正
应用状态一旦与 Git 仓库中期望状态不一致，应该立刻进行自动修复，即使手动修改了集群的编排策略，集群也会被自动恢复到 Git 仓库中清单所描述的状态。以 Git 仓库作为基础设置和应用的单一事实来源，从而杜绝各类权限分散、手动操作的弊端。
分支管理模型 Aone Flow
为满足各类场景开发需求，我们可以在 Git 中定义不同用途的分支以及分支的合并策略，这就是分支模型。
常用的 Git 分支模型有 Gitflow、主干开发模型、Aone Flow 等分支管理方法。
| Gitflow | 主干开发 | Aone Flow | |
|---|---|---|---|
| 代表公司 | Git Prime | 阿里 | |
| 使用场景 | 瀑布式 | 持续交付 | 持续交付 |
| 操作复杂度 | 中等 | 简单 | 复杂（需要系统自动化） |
| 并行开发 | 支持 | 支持 | 支持 |
| 下线特性分支 | 手动 | 手动 | 可自动化 |
| 随时发布 | 不支持 | 支持（开关隔离） | 支持 |
Aone Flow 定义了三种分支类型 - 特性分支(feature)、发布分支(release)与主干分支(Master)。
开发人员在收到开发任务后，会从 Master 分支拉取专用的 feature 分支。在 feature 分支完成开发工作后，将 feature 并入 release 分支进行集成测试。 测试人员发布分支并完成测试工作后，由开发或运维人员将 release 分支部署到正式环境，然后再将 release 分支合并进入 Master 分支。
以图为例，开发人员 A 与 开发人员 B 收到两个开发任务后，分别创建特性分支 feature/001，feature/002，并进入开发工作。开发工作完成后，他们需要将 feature/001 feature/002 发布到日常环境进行集成测试。于是创建一个发布分支 release/daily，并将 feature/001 feature/002 合并到该分支中。
feature/001 通过了测试，但 feature/002 还存在较多 bug，此时 feature/001 可以独立发布到正式环境。为了避免 feature/002 对测试造成干扰，我们需要将 feature/002 解除合并，单独对 feature/001 进行回归验证。
由于 Git 中去除一个已经合并分支所有的提交较为繁琐，我们可以重新创建一个日常环境的 release 分支，仅合并待测试的 feature/001 分支，为了避免与旧 release 分支名字冲突，我们可以采用 release/20220304 此类的日期分类方式。
0 评论