我們大多數人在註意到 IT 部落格圈或會議中的另一個新術語時，遲早會問一個類似的問題：「這是什麼？ 只是另一個流行詞，一個“流行詞”，還是真正值得密切關注、研究並有望帶來新視野的東西？ 同樣的事情也發生在我身上 Git 操作 前一段時間。 擁有許多現有文章以及公司同事的知識 ，我試圖弄清楚這是什麼野獸，以及它在實踐中的用途可能是什麼樣的。
順便說一下，關於這個詞的新穎性 Git 操作 我們最近的調查也顯示：超過一半的受訪者尚未開始遵循其原則。
因此，基礎設施管理問題並不新鮮。 許多雲端供應商已經向公眾開放了十多年，而且看起來應該使負責基礎設施的團隊的工作變得簡單明了。 然而，與應用程式開發流程（自動化達到新的水平）相比，基礎設施專案仍然經常涉及許多手動任務，並且需要專門的知識和專業知識，特別是考慮到當今對容錯性、靈活性、可擴展性和彈性的要求。
雲端服務非常成功地滿足了這些要求，並且正是它們極大地推動了該方法的發展 交流電。 這是可以理解的。 畢竟，它們使得配置完全虛擬的資料中心成為可能：沒有實體伺服器、機架或網路元件；整個基礎架構可以使用腳本和設定檔來描述。
那麼到底有什麼差別呢？ Git 操作 從 交流電？ 帶著這個問題，我開始了我的調查。 經過與同事的交談，我得出了以下比較：
Git 操作
交流電
所有程式碼都儲存在 git 儲存庫中
程式碼版本控制是可選的
聲明性代碼描述/冪等性
聲明性和命令性描述都是可以接受的
使用合併請求/拉取請求機制變更生效
協議、批准和協作是可選的
更新推出流程是自動化的
更新推出過程不標準化（自動、手動、複製檔案、使用命令列等）
換句話說 Git 操作 正是透過應用這些原則而誕生的 交流電。 首先，基礎設施和配置現在可以以與應用程式相同的方式儲存。 程式碼易於儲存、易於共享、比較和使用版本控制功能。 版本、分支、歷史。 所有這些都在整個團隊可以公開訪問的地方。 因此，版本控制系統的使用就成為完全自然的發展。 尤其是git，最為流行。
另一方面，基礎設施管理流程的自動化成為可能。 現在，這可以更快、更可靠、更便宜地完成。 此外，CI/CD 的原理在軟體開發人員中已經眾所周知並流行。 只需要將已知的知識和技能轉移並應用到新的領域。 然而，這些實踐超越了基礎設施即程式碼的標準定義，因此出現了這個概念 Git 操作.
好奇心 Git 操作當然，事實上它不是與任何供應商相關的產品、插件或平台。 它更多的是一種範式和一組原則，類似於我們熟悉的另一個術語：DevOps。
該公司 我們為這個新術語制定了兩個定義：理論和實踐。 讓我們從理論開始：
GitOps 是一種採用用於應用程式開發的最佳 DevOps 原則（例如版本控制、協作、編排、CI/CD）的方法，並將其應用於自動化基礎架構管理的挑戰。
所有流程 Git 操作 我使用現有工具進行工作。 所有基礎設施程式碼都儲存在已經熟悉的git 儲存庫中，更改與任何其他程式碼都經過相同的審批流程，並且部署過程是自動化的，這使我們能夠最大限度地減少人為錯誤，提高可靠性和可重複性。
我們從實際的角度來描述 Git 操作 如下所示：
我們已經討論過基礎設施即程式碼是這個公式的關鍵組成部分之一。 讓我們介紹一下其餘的參與者。
合併請求（又稱拉取請求）。 用流程術語來說，MR 是應用程式碼變更然後合併分支的請求。 但就我們使用的工具而言，這更多的是一個全面了解所有所做更改的機會：不僅是從一定數量的提交中收集的程式碼差異，還包括上下文、測試結果和最終預期結果。 如果我們談論基礎設施程式碼，那麼我們感興趣的是基礎設施將如何變化，將添加或刪除、更改多少新資源。 最好採用一些更方便且易於閱讀的格式。 對於雲端供應商來說，最好了解這項變更的財務影響。
但混合實境也是一種協作、互動和溝通的方式。 這是製衡制度發揮作用的地方。 從簡單的意見到正式的認可和認可。
好吧，最後一個元件：CI/CD，如我們所知，可以自動化基礎架構變更和測試的過程（從簡單的語法檢查到更複雜的靜態程式碼分析）。 以及隨後的漂移偵測：系統的真實狀態和期望狀態之間的差異。 例如，由於未經授權的手動更改或系統故障。
是的，這個詞 Git 操作 不會向我們介紹任何全新的東西，也不會重新發明輪子，而只是將已經累積的經驗應用到新的領域。 但這正是他的強項所在。
如果您突然對這一切在實踐中的表現感興趣，那麼我邀請您看看我們的 ，其中我一步步告訴你如何使用GitLab：
-
實施 GitOps 的基本原則
-
建立並變更雲端基礎架構（以 Yandex Cloud 為例）
-
使用主動監控自動偵測系統偏離所需狀態的情況
https://bit.ly/34tRpwZ
來源： www.habr.com