GitOps 是一种运维框架，它采用了 DevOps 在应用程序开发阶段的最佳实践（例如版本控制、协作、合规性和 CI/CD 工具），并将其应用于基础设施自动化。尽管软件开发生命周期已实现自动化，但基础架构大体上仍然是一个需要专业团队进行手动操作的过程。随着对基础架构需求的不断增长，实现基础设施自动化变得越来越重要。现代化的基础设施需要弹性，以便能有效地管理持续部署所需的云资源。

速度和规模对于现代应用程序的开发对至关重要。具备成熟 DevOps 文化的团队每天可以进行数百次的代码部署。DevOps 团队可以通过开发最佳实践，如版本控制、代码评审以及可自动执行测试和部署的 CI/CD 流水线，来实现这一点。

GitOps 用于对基础设施置备的过程进行自动化。与团队使用应用程序源代码的方式类似，采用 GitOps 的运维团队将配置文件存储为代码（基础设施即代码）。GitOps 配置文件在每次部署时都会生成相同的基础设施环境，就像应用程序源代码在每次构建时都生成相同的应用程序二进制文件一样。

团队如何将 GitOps 付诸实践？

GitOps 不是简单的一个产品、插件或平台。GitOps 工作流可帮助团队通过已在应用程序开发过程中使用的流程来管理 IT 基础设施。

GitOps 需要三个核心组件

GitOps = 基础设施即代码（IaC）+ 合并请求（MR）+ 持续集成（CI）/ 持续交付（CD）

基础设施即代码（IaC）：GitOps 使用 Git 仓库作为基础设施定义的单一可信来源。Git 是一个开源版本控制系统，可跟踪和管理代码变更。Git 仓库是项目中的.git 文件夹，可跟踪一段时间内对项目中所有文件的更改。基础设施即代码是将所有基础设施的配置存储为代码的做法。实际的目标状态可以以代码形式存储，也可以不以代码的形式存储（例如，副本数或 Pod 数会存放在 etcd 中）。

合并请求（MR）: GitOps 使用合并请求作为所有基础设施更新的变更机制。合并请求是团队通过评审和评论进行协作的地方，也是执行正式批准的地方。合并会被提交到您的主 (或主干) 分支，并可作为审计日志。

持续集成（CI）/持续交付（CD）：GitOps 使用具有持续集成和持续交付（CI / CD）的 Git 工作流来自动化执行基础架构的更新。在新代码合并后，CI/CD 流水线将执行环境中的更改。GitOps 会自动化覆盖任何配置变动（例如手动更改或错误），因此，真实环境会趋于 Git 中定义的预期状态。极狐GitLab使用 CI/CD 流水线来管理和实现 GitOps 自动化，但是也可以使用其他形式进行自动化，例如定义 Operator。

GitOps 挑战

对于任何需要协作的工作，改变都是很棘手的，GitOps 也不例外。GitOps 需要所有参与者遵守纪律，它是一种采用全新的方式来工作的承诺。对于团队来说，把所有的事情都记录下来至关重要。

GitOps 支持进行更大程度的协作，但这对于某些个人或组织而言不一定是很自然的事情。GitOps 的审批过程意味着开发人员要对代码进行更改、创建合并请求，而批准者要合并这些更改并进行部署。这一系列过程为基础设施引入了“委员会式变更”机制。对于习惯于快速手动更改的工程师来说，这似乎是一件乏味且耗时的事情。

对于团队中的每个人来说，记录合并请求和议题中发生的事情非常重要。在生产环境中直接编辑或手动更改某些内容的诱惑很难抵制，但是“牛仔式编程”越少，GitOps 就会运转得越好。

是什么让 GitOps 起作用？

与任何新兴的技术术语一样，整个行业对 GitOps 并没有严格的定义。GitOps 原则可应用于所有类型的基础设施自动化，包括虚拟机和容器，并且对于希望管理基于 Kubernetes 基础设施的团队而言非常有效。

价值流分析能帮助你识别工作流中效率低下的地方和根因。在 13.12 版本里，我们推出了工作流内容的分页和排序功能，帮助你在一个指定的 stage 里快速查看和整理内容来定位瓶颈。完成时间（Days to Completion）图表也已升级，能显示平均完成时间指标（average time to completion），帮助识别更有意义的时间趋势。

尽管许多工具和方法都承诺在代码和基础架构之间能够实现更快的部署和无缝管理，但 GitOps 的不同之处在于，它致力于提高以开发人员为中心的体验。通过 GitOps 进行的基础设施管理与应用程序开发在同一版本控制系统中进行，这使团队可以在一个集中的地方进行更广泛的协作，同时从 Git 的内置功能中受益。