GitOps描述了一种使用植根于 Git 版本控制系统的方法来操作和管理软件的方法。使用基于 GitOps 的工作流，通过要求将系统的特征定义为 Git 存储库中的文件，可以更轻松地开发、部署、维护和协作软件。
术语暗示了 Git 作为单一事实来源的角色。然而，GitOps 驱动流程的实际实现历来是可以解释的。现在， OpenGitOps标准已经解决了这种模糊性，这是CNCF 支持的定义导致可重复 GitOps 系统的原则的尝试。
在本文中，我们将了解这些原则是什么，它们为何重要，以及如何使用它们来构建可扩展和可维护的软件。这些标准是根据GitOps 工作组中 90 多家领先公司和相关方的见解制定的。
1. 声明状态
第一个原则指出，所有 GitOps 管理的系统都必须以声明方式表达其状态。您应该定义理想状态在当前时间点的样子，而不是提供有关如何组装该状态的具体说明。
声明式配置将系统的所需状态与用于转换到该状态的过程分开。随着时间的推移，这更易于维护并且更容易推理；贡献者只需要描述系统现在应该看起来的样子，无需编写影响状态更改的迁移。
不定义实现状态的确切步骤可以节省开发时间并提高部署灵活性。您只需应用存储库中的最新状态定义，即可在新环境中启动应用程序实例。
声明式配置通常与Ansible 和 Terraform 等基础设施即代码工具一起使用。您编写配置文件来定义您希望