特性开关和 GitOps, 5个用例帮您搞定。
GitOps 的实践是持续交付的下一个替代。它允许开发人员进入 IT 运维的传统工作范围-许多历史关卡的所在地-自动更新生产环境的应用程序和运行程序的基础设施。在 GitOps 中，所有变更管理和版本控制的唯一可信来源是软件配置管理（SCM）。GitOps 抛弃了传统 ITIL 类型的管理，将基础设施和应用程序视为版本化的制品，包括在软件开发期间捕获的相同粒度的审计轨迹（提交 ID，时间戳等）。
我的看法
GitOps 的思想是通过 Git 提交将整个系统的期望状态存储在版本控制系统中。从本质上，您可以将 GitOps 视为一个文件版本控制系统。GitOps 一个关键的原则是通过使用遵守声明式规范的配置文件描述应用程序和环境的期望状态。
这意味着配置根据实际情况而不是操作指南列表管理。它给你一个规则来检查结果是否正确，而不是给你一个配置清单去创建一个系统。你可以用这种方式描述你整个的 CI/CD 流水线并将其放在代码仓库中。为了变更到期望的状态，开发人员发出一个 Pull rquest ，这基本上告诉所有人您已发布到仓库的变更，并告知仓库将变更拉入。通过使用Git，您可以获得版本历史记录、审核日志、回滚功能以及查看谁更改了什么以及何时更改的功能。
特性开关 + GitOps
当我们考虑 GitOps 时，会立即想到的用例是容器编排和集群管理—特别是使用声明性工具 Kubernetes。没有多少人会立即想到[特性标志][1]。那么为什么我们认为特性标志这么重要？这很重要，因为 GitOps 的愿景是对整个系统的全面控制。特性开关通常被视为“规则之外”的活动。我们相信，特性开关-尤其是达到一定规模-将成为一个非常强大的工具，如果它们的管理方式与代码的其他部分一样严格、管理和受重视。如果要使用 GitOps 来管理特性开关，则必须使用配置文件描述它们所需的状态。但这还不是全部。
有一种正确的方法可以将 GitOps 应用于特性开关
特性开关是一个粘性的小窗口。它们拥有进行生产变更的能力，但它们不会像其他代码一样承担生产准备就绪的检验的责任。如果它要成为软件交付生命周期的一部分，就需要不断发展。
如果我们想用 GitOps 管理特性标志，那么所需的状态（由声明性规范描述）必须保存到配置文件中。我们使用 YAML，以便它是人类可读和可编辑的。当需要更新到期望的状态时，只需简单的合并配置即可。此变更通过建立了审核跟踪的PR提交，并确保正确的人员正在验证更改—这正是当有人更改应用程序中的代码或更新基础设施设置时所发生的更改。我们相信这是用 GitOps 管理特性开关的正确方法。这也是最符合供应商中立的愿望的做法。
据我们所知，只有[ CloudBees Rollout ][2]能够支持这一点。我们的一些竞争对手也有一个配置文件，他们的SDK知道如何读取和更改它。但是，它不是可编辑的。它也不会自动保存在像 GitHub 这样的 SCM 中。它们迫使用户绕过管理代码的既定过程，以便管理特性开关。例如，如果需要功能回滚，客户将被迫使用第三方仪表板，而不是 Git。
使用 CloudBees Rollout 管理特性开关的一些‘Git’用例
[配置即代码][3]，这个术语经常与基础设施作为代码（IaC）互换使用，但它实际上是不同的。IaC 是关于基础设施栈的管理和配置，而 CaC 是关于在环境之间自动迁移配置。这都是为了进行环境配置的有力工具。不允许有雪花。我们对待特性开关的方式与配置对待应用程序的方式相同（我们在这里使用 CaC 术语而不是 IaC，因为特性开关不是基础设施的一部分，而是在软件应用程序上）。当我们讨论 GitOps 时，这意味着我们可以用 PR 跟踪 SCM 中应用程序的变更和版本控制的方式，记录特性开关中发生的更改和版本控制。将更改推送到主分支通过 SDK 触发一个待处理的事件。然后，系统知道如何将特性开关更新到 YAML 文件配置所期望的状态。
CloudBees Rollout 将所有特性开关和目标数据存储为保存在 Git 存储库中的本地 YAML 文件。对本地 YAML 文件进行更改将更新 CloudBees Rollout 功能标记数据。我们利用 Git 的分布式版本控制系统的特性，即使在本地工作，也允许您有完整的可追溯性和修订历史的能力。如果直接在 GitHub 中编辑特性开关并将更改提交到主分支，则事件将被触发回仪表板，并反映在 Rollout 的审核日志中。如果更改是通过仪表板完成的，仪表板就像一个 Git 客户机，并将更新 GitHub 上的 YAML 文件。
一旦你用配置即代码来处理你的特性开关，你就可以实现这些很棒的用例；
1. 治理和责任感：因为所有更改都在Git中，所以每次提交都会产生审计跟踪。你知道谁更改了你的特性开关中的内容和时间。因为所有的事情都是由 PR（Pull Rquest）管理的，所以你可以让团队成员批准你的变更，以增加责任感。
2. 渐进式交付、变更和版本控制：特性开关允许您将功能部署与代码发布分离。当将功能提交到主分支时，通过将功能包装到特性开关中，消除长期的分支。特性可以保持“关闭”状态，直到代码完成。在 Git 中减少分支可以让你做渐进式发布（通过少量发布，增加发布速度）。基于 GitOps 的特性开关方法可以确保每一个变更都被考虑在内。
3. 克隆环境：通过配置及代码，您可以克隆环境（dev、QA、prod、功能 X、Y、Z）之间的功能配置，通过跟踪功能切换变更。
4. 特性开关自动化：当您有描述系统期望状态的可编辑的配置文件时，您很容易基于各种期望状态运行自动化（用于测试或部署目的）。您可以使用 GitOps 方法将特性开关标记的功能自动部署到用户群的一个子集或各种分段。当将特性开关作为一个配置文件时，很容易将系统迁移到新的期望的状态。其他替代方法，如使用 rest API 更改特性标志的传统 CI 过程，则更为复杂。与等待对服务器的身份验证，等待网络向服务器报告然后。。。然后。。。相比，使用 GitOps 管理特性开关就像更改 Git 仓库中的配置文件以更改状态一样简单。
5. 通过 Git 命令回滚功能变更： 每个开发人员都曾经遇到过，需要回滚某个提交。您可以通过一个简单的 git revert 命令使用特性开关来实现这一点。由于 CloudBees Rollout 将配置代码保存在 Git 中，因此您可以使用分支隔离更改以及时回滚，并在并行流中工作，而不会影响生产/预备环境。
尽管采用 GitOps 仍然是团队的理想选择，您也可以使用 CloudBees Rollout 来管理您的特性开关。API集成允许您链接到您最喜欢的性能、分析、监控和 APM 工具，使之更容易适应，而不管您如何管理 Dev 和 Ops 之间的桥梁。