特性开关和 GitOps, 5个用例帮您搞定

GitOps 的实践是持续交付的下一个替代。它容许开发人员进入 IT 运维的传统工做范围-许多历史关卡的所在地-自动更新生产环境的应用程序和运行程序的基础设施。在 GitOps 中，全部变动管理和版本控制的惟一可信来源是软件配置管理（SCM）。GitOps 抛弃了传统 ITIL 类型的管理，将基础设施和应用程序视为版本化的制品，包括在软件开发期间捕获的相同粒度的审计轨迹（提交 ID，时间戳等）。

01.个人见解

GitOps 的思想是经过 Git 提交将整个系统的指望状态存储在版本控制系统中。从本质上，您能够将 GitOps 视为一个文件版本控制系统。GitOps 一个关键的原则是经过使用遵照声明式规范的配置文件描述应用程序和环境的指望状态。

这意味着配置根据实际状况而不是操做指南列表管理。它给你一个规则来检查结果是否正确，而不是给你一个配置清单去建立一个系统。你能够用这种方式描述你整个的 CI/CD 流水线并将其放在代码仓库中。为了变动到指望的状态，开发人员发出一个 Pull rquest ，这基本上告诉全部人您已发布到仓库的变动，并告知仓库将变动拉入。经过使用Git，您能够得到版本历史记录、审核日志、回滚功能以及查看谁更改了什么以及什么时候更改的功能。

02.特性开关+GitOps

当咱们考虑 GitOps 时，会当即想到的用例是容器编排和集群管理—特别是使用声明性工具Kubernetes。没有多少人会当即想到特性标志。那么为何咱们认为特性标志这么重要？这很重要，由于 GitOps 的愿景是对整个系统的全面控制。特性开关一般被视为“规则以外”的活动。咱们相信，特性开关-尤为是达到必定规模-将成为一个很是强大的工具，若是它们的管理方式与代码的其余部分同样严格、管理和受重视。若是要使用 GitOps 来管理特性开关，则必须使用配置文件描述它们所需的状态。但这还不是所有。
**
03.将GitOps应用于特性开关**

特性开关是一个粘性的小窗口。它们拥有进行生产变动的能力，但它们不会像其余代码同样承担生产准备就绪的检验的责任。若是它要成为软件交付生命周期的一部分，就须要不断发展。

若是咱们想用 GitOps 管理特性标志，那么所需的状态（由声明性规范描述）必须保存到配置文件中。咱们使用 YAML，以便它是人类可读和可编辑的。当须要更新到指望的状态时，只需简单的合并配置便可。此变动经过创建了审核跟踪的PR提交，并确保正确的人员正在验证更改—这正是当有人更改应用程序中的代码或更新基础设施设置时所发生的更改。咱们相信这是用 GitOps 管理特性开关的正确方法。这也是最符合供应商中立的愿望的作法。

据咱们所知，只有 CloudBees Rollout 可以支持这一点。咱们的一些竞争对手也有一个配置文件，他们的SDK知道如何读取和更改它。可是，它不是可编辑的。它也不会自动保存在像 GitHub 这样的 SCM 中。它们迫使用户绕过管理代码的既定过程，以便管理特性开关。例如，若是须要功能回滚，客户将被迫使用第三方仪表板，而不是 Git。

04.管理特性开关Git 用例

配置即代码，这个术语常常与基础设施做为代码（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 之间的桥梁。

本文转自公众号 Jenkins中文社区做者 Kristin Baskett