在当今竞争激烈的环境中，你需要在不影响质量的情况下快速交付软件特性。但是对于大多数组织来说，能跟上当前最新的版本管理实践技术，并能和传统的操作过程和谐共存是很困难的。
现在，随着开发人员采取端到端“你构建，你拥有”的方法来实现软件的开发过程，他们需要使用他们最熟悉的工具和方法来快速适应变化。
在最近的伦敦Continuous Lifecycle会议上，Alexis Richardson发表了题为“GitOps: Git Push All the Things”的主题演讲，他讨论了行业挑战，包涵当前CI/CD发展趋势和如何将这些工具与进程的操作与监控融合起来。此外，Alexis还阐明了如何运用GitOps更好的实践，开发人员可以使用其最熟悉的工具来控制开发与操作管道。
GitOps三原则
GitOps可以概括为以下原则:
1.所有可以被描述的内容都必须存储在git中
通过使用Git作为开发事实的来源，从业人员可以观察集群并将其与所需的状态进行比较。策略、代码、配置项，甚至监控事件和版本控制都可以实现。将所有内容都置于版本控制系统后，所有我们提交的变化都被聚合起来，这样那些我们提交的没有被应用的代码也有可能被再应用起来。
2.不能直接使用Kubectl
普遍来说，使用命令行工具集“kubectl”来直接部署到集群并不是个好办法。许多人士使用他们的CI工具驱动部署，然而这样做可能会给产品开发带来众所周知的安全漏洞。
3.使用符合操作模式的Kubernetes控制器
使用遵循操作模式的Kubernetes控制器，你的集群总是通过已核对好的Git的配置文件与“真实之源”保持同步。由于你的集群的期望状态保存在Git中，因此你可以观察到它与运行的集群的差异。
Alexis进一步阐述了第三点，他描述了如何通过比较Git中所需的状态和运行中的集群状态，来观察差异，并在两种状态不同步的时候提醒您的团队。通过在集群中安装Kubernetes操作符，不仅从认证的角度来看部署更安全，而且还允许有效的控制和反馈环。你的团队可以使用这些数据来迭代和改进产品特性以及集群基础设施的更新。
如果你描述了所有的东西，并将其保持在版本控制中，那么可以被描述的东西既可以被验证也可以被自动化。这为您提供了在版本控制中保持系统的正确描述并使用它来自动化整个系统的机制。” - Alexis Richardson
观看完整演讲打开如下地址: https://youtu.be/uWzgmmCzdF4
