GitOps

GitOps 是一项通过控制回路模式进行应用部署的技术。Operator 能够将已部署的应用和配置（通常是 Git 仓库）保持同步。当我们上次写到 GitOps 的时候，社区对此术语的定义未能形成共识。当时，我们对该技术的常见解读抱有疑虑，因为部分解读包含不恰当的做法。例如，使用“环境分支”就可能导致雪花即代码的出现。此外，“GitOps 是持续交付的一种替代方案”这个说法也令人困惑。在那之后，四个 GitOps 原则澄清了该技术的范围和性质。当拨开炒作和混乱的迷雾，你会发现 GitOps 是一项基于 Kubernetes 集群功能的有用技术，为分离介于配置应用和实施部署流程的关注点创造了机会。我们的一些团队在他们的持续交付设置中实施了 GitOps ，并取得了良好的体验。所以我们推荐大家去评估这项技术。

我们建议在采用 GitOps 时一定要谨慎，尤其是在分支策略方面。GitOps可以被视作一种基础设施即代码的实现方式，这种方式持续地从Git同步基础设施代码，并将其部署到多个环境当中。在为每个环境创建一个分支的场景下，对基础设施的修改会通过合并代码的方式从一个环境应用到下一个环境。诚然，将代码作为基础设施修改的唯一来源，是一种合理的方式，但我们发现对每个环境创建分支会导致环境之间的不一致。最终，合并特定环境的配置代码带来了许多问题，甚至导致这种方式被废弃。这与我们之前在Gitflow的长期分支当中看到的情景非常相似。