特性開關和 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