GitOps 是一種自動化和管理基礎架構和應用程式的模型，透過許多團隊已經使用的相同 DevOps 最佳實踐來形成的模型，例如版本控制、程式碼審查和 CI/CD 流水線。在實施 DevOps 時，我們找到了自動化軟體開發生命週期的方法，但在基礎設施設定和部署方面，仍然依靠手動過程。藉助 GitOps，團隊可以自動化基礎架構配置過程，同時能夠編寫 IaC、在 Git 儲存庫中對程式碼進行版本控制，以及將持續部署原則應用於雲交付。
許多公司一直在採用 GitOps，因為 GitOps 具有提高生產力和軟體質量的巨大潛力，同時它也最適合開發基於容器化和微服務的雲原生解決方案的企業。
GitOps 如何最佳化開發運維環境
GitOps 帶來的更好的基礎設施自動化，創造了為應用程式開發人員開發“自助服務”的機會。熟練的開發人員可以使用基礎設施即程式碼來宣告他們的雲資源需求，這成為基礎架構的理想狀態，因為集中儲存並作為程式碼中規定的要求與實時環境的實際狀態之間的不可變參考點。自助服務方法正在解放開發人員，提高了開發人員的工作效率，使他們能夠專注於開發和創新，並更快地將應用程式推向市場。此外，自助服務避免了當開發人員和運營商需要協商資源時可能產生的一些問題與矛盾。
另一方面，人們經常誤認為運維自動化程度的提高意味著運維團隊需要的人員更少，並且運維在流水線中的作用被邊緣化了。然而並非如此，我們相信 GitOps 和內部開發人員平臺等現代方法為運維團隊提供了更多機會來提高他們的技能併為企業創造更多價值。運維團隊實際使用的技術可能會有所不同。在某些情況下，可能只是一個 PaaS 解決方案。在其他情況下，可能是各種工具的組合從而建立適合企業需求的定製平臺。這使運維人員能夠對基礎設施資源和架構施加更大的影響和控制，並建立“護欄”，強制採用簡單、高效和標準化的方法來部署雲原生應用程式。
GitOps 有助於改善開發人員和運維團隊之間的協作，提高他們的生產力，並提高部署頻率。GitOps 使開發人員能夠在無需瞭解底層基礎架構的情況下貢獻功能，從而有效提高了開發人員的體驗。同時，它透過程式碼審查和批准來控制操作。透過這些改進，團隊可以更快、更安全地釋出軟體，從而保持企業在市場中的地位。
實施 GitOps 的三個關鍵步驟
想要獲得在公司中實施 GitOps 模型的最顯著優勢，例如整體工作流程的標準化和一致性，建議企業考慮以下事項。
一切皆程式碼（Everything as Code）
- 宣告 IaC。
- 使用 Git 儲存庫進行 IaC 開發。
- 將作為應用程式程式碼生命週期一部分的實踐複製到基礎架構程式碼中。
- 使用 Docker 和 Kubernetes 等技術，將環境、版本、配置和依賴項定義為程式碼，並確保它們在執行時得到執行。
- 逐漸將 GitOps 模型擴充套件到任何可以定義為程式碼的事物，例如安全性、策略、合規性和基礎設施之外的所有操作。
圖片來源：Microtica
宣告式程式碼提高了可讀性和維護性。CloudFormation、Terraform、Pulumi 和 Crossplane 是一些可用的宣告性語言，企業可以嘗試使用這些語言來定基礎架構的外觀配置。當一切都定義為程式碼時，可以使用 Git 儲存庫進行開發並探索版本控制、協作和審計等優勢。
審查程式
正確的 Git 流程包括：
- 主分支，通常代表一個環境，如 dev、test、stage、prod 和在該環境上執行的狀態。
- 當開發人員需要對程式碼進行更改時，他們會從主分支建立一個新分支。
- 當更改準備就緒時，開發人員建立一個拉取請求，該請求應由操作人員審查以驗證和批准。安全和合規專家也可以參與此階段以正確驗證環境狀態。
- 一旦獲得批准，程式碼就可以合併到主分支中並交付給測試或生產。
- 使用此工作流程，可以跟蹤誰進行了哪些更改並確保環境具有正確的程式碼版本。
圖片來源：Microtica
如果企業已經透過使用功能分支和拉取請求來利用 Git 流程系統，那就不需要為新的 GitOps 工作流程投入太多。此外，由於基礎架構（和其他操作）被定義為程式碼，企業將能夠實施相同的程式碼審查實踐。
獨立的構建和部署過程（CI 和 CD）
- CI 流程負責構建應用程式程式碼並將其打包到容器映象中。
- CD 過程執行自動化以使最終狀態與系統的期望狀態一致，如儲存庫程式碼中所述。
最終，GitOps 將 CI 和 CD 視為兩個獨立的流程——CI 作為開發流程，CD 作為運營流程。 通常用於分離這些程式的 GitOps 方法是引入另一個 Git 儲存庫作為中介。這個 repo 包含關於環境的資訊，每次提交都會觸發部署過程。在流水線和編排工具之間有一個操作器元件。操作員不斷地將環境儲存庫中的目標狀態與已部署基礎設施中的實際狀態進行比較。如果操作員檢測到任何更改，則會更改基礎架構以適應環境儲存庫。此外，它還監控映象倉庫以識別要部署的新版本映象。這樣，CI 過程就不會觸及底層基礎設施（例如，Kubernetes 叢集）。
圖片來源：Microtica
將構建流水線與部署流水線分離是防止錯誤配置的有力保護措施，有助於實現更高的安全性和合規性。
結論
使用 GitOps，企業可以自動化基礎架構配置過程，並將 Git 用作基礎架構的單一真實來源。因此，要建立成功的 GitOps 模型，需要對環境進行宣告性定義。建議企業團隊最好具備拉取請求工作流程，以便在基礎架構程式碼上進行協作並建立操作更改。資深 DevOps 工程師和安全專家隨後審查拉取請求以驗證更改並在一切正常時將它們合併到主分支中。企業需要使用 CI/CD 自動化來供應和配置底層環境以及部署定義的程式碼，以確保完整的 GitOps 實施。
最後，公司內部應當培養一種支援性的文化。GitOps 流程很自然地形成了一種結構，在這種結構中，開發人員可以從自助服務基礎設施資源中獲得更高的自動化程度，而運維工程師可以在過程中扮演更有影響力的角色。
參考連結：
https://danielkummer.github.io/git-flow-cheatsheet/
https://dzone.com/articles/3-steps-to-developing-a-successful-gitops-model