GitOps 和 DevOps 有一些相同的原則和目標。DevOps 是關于文化變革的，并為開發團隊和運維團隊提供了一種協同工作的方式。GitOps 提供了采用 DevOps 實踐（如協作、CI/CD 和版本控制）的工具和框架，并將其應用于基礎設施自動化和應用程序部署。
(資料圖)
現代信息社會，快速穩定的交付客戶所需的應用是企業成功的關鍵，隨著時代發展，開發現代應用程序與過去的方法不同，許多團隊開始探索使用DevOps來加速實現自己的業務價值。
DevOps：加速價值交付
DevOps 描述了加快流程的方法，通過這些流程，可以快速將一個想法（如新的軟件功能、增強請求或錯誤修復）實現從開發到部署，并最終為用戶提供價值。這些方法要求開發團隊和運維團隊保持持續溝通，并用同理心來處理他們的工作。雙方一起密切合作，在不犧牲可靠性的情況下加快軟件構建、測試和發布。
DevOps是“development”和“operations”的混搭，但它不僅代表了開發和運維，更代表了一組想法和實踐，包括安全性、協作工作方式、數據分析和許多其他內容。同時DevOps 也依賴于開源原則和透明、敏捷的工作方式相一致的協作文化。
DevOps 加快了創意從開發到部署的過程。DevOps 的核心依賴于在應用的整個生命周期中自動執行日常操作任務和標準化環境。容器可以提供標準化的環境，大規模容器需要一個平臺來管理它們，并結合自動化能力支持。
引入DevOps改變的不僅僅是工作方式，所做的工作也不可避免地會改變。DevOps 不僅僅是加快創建單體軟件，而是創建更適合這種持續交付節奏的新型軟件。這就是為什么 DevOps 團隊通常會使用微服務架構構建軟件并將這些服務與 API 連接在一起的原因。團隊通過專注于創建較小的功能來更快地交付。
CI/CD：通過自動化加速交付
CI/CD（Continuous integration/continuous deployment）是一種通過將自動化引入應用開發階段來頻繁向客戶交付應用的方法。CI/CD 的主要概念是持續集成、持續交付和持續部署。
CI/CD 是 DevOps 方法的支柱，它將開發人員和運維團隊聚集在一起部署軟件，讓代碼發布的速度成為競爭優勢。
CI/CD 在整個應用程序生命周期（從集成和測試階段到交付和部署）中應用自動化，以快速生成經過測試和驗證的應用程序。它包含兩個不同但相關的功能：
持續集成 （CI）幫助開發人員快速驗證功能，并更頻繁地將其代碼更改合并回共享分支。通過自動構建應用程序并運行不同級別的自動化測試（通常是單元測試和集成測試）來驗證合并的代碼更改，以確保更改正常工作。如果測試發現新代碼和現有代碼之間存在沖突，CI 可以更輕松、更快速地修復這些錯誤。持續部署 （CD）自動執行將應用程序發布到生產環境的過程。在生產前的開發管道階段，很少有手動干預，因此CD嚴重依賴精心設計的測試自動化。因此，如果開發人員對云應用程序的更改通過所有自動化測試，則它可以在編寫云應用程序后的幾分鐘內上線。CD 使持續接收和合并用戶反饋變得更加容易。CI/CD 允許以較小的部分發布對應用程序的更改，從而使應用程序部署更加可靠。同時也可以將 CI/CD 應用于組織內的許多組件和資產，包括應用程序、平臺、基礎結構、網絡和自動化代碼。
基礎設施即代碼IaC
基礎設施即代碼（Infrastructure as Code, IaC）是實施 DevOps 實踐和持續集成/持續交付 （CI/CD） 的重要組成部分。IaC 可以標準化開發與運維團隊的交互方式，并確保基礎設施的一致性，釋放開發與運維的大部分準備和協調工作。
配置基礎設施歷來是一個耗時且成本高昂的手動過程。現在，基礎設施的管理已經從數據中心的物理硬件（盡管這仍然是您組織的組件）轉向虛擬化、容器和云計算。借助云計算，基礎設施組件的數量不斷增長，每天都有更多的應用程序發布到生產環境，并且基礎設施需要能夠頻繁地啟動、擴展和關閉。如果沒有 IaC ，管理當今基礎設施的規模變得越來越困難。
與此同時，CI/CD 依賴于從集成和測試到交付和部署的整個應用程序生命周期的持續自動化和持續監視。為了使環境自動化，需要保持一致。當開發團隊以一種方式部署應用程序或配置環境，而運維團隊以另一種方式部署和配置環境時，自動化應用程序部署不起作用。通過 DevOps 方法協調開發和運營團隊可以減少錯誤、手動部署和不一致。IaC 可幫助協調開發和運維，兩個團隊可以使用相同的應用程序部署描述，從而支持 DevOps 實踐。
DevOps 最佳實踐也適用于 IaC 中的基礎設施。基于IaC，基礎設施可以實現與應用程序在軟件開發期間相同的 CI/CD 管道，對基礎設施代碼應用相同的測試和版本控制。這引出了GitOps。
GitOps
GitOps 可以被視為基礎設施即代碼 （IaC） 的演變，并使用 Git 作為基礎設施配置的版本控制系統。IaC 通常通過定義系統的所需狀態并跟蹤系統的實際狀態來遵循聲明性基礎設施的管理方法。與 IaC 一樣，GitOps 要求以聲明方式描述系統的所需狀態。通過使用聲明性工具，可以在 Git 中對所有配置文件和源代碼進行版本控制。
GitOps 提供：
應用程序開發的標準工作流程提高了預先設置應用程序要求的安全性通過 Git 提高可見性和版本控制的可靠性跨任何集群、任何云和任何本地環境的一致性通過使用開發人員熟悉的基于 Git 的相同工作流，GitOps 擴展了從應用程序開發到部署、應用程序生命周期管理和基礎設施配置的現有流程。整個應用程序生命周期中的每個更改都會在 Git 存儲庫中進行跟蹤，并且是可審核的。通過 Git 進行更改意味著開發人員最終可以做他們想做的事：按照自己的節奏編寫代碼，而無需等待運維團隊分配或批準資源。
對于運維團隊而言，變更可見性意味著能夠快速跟蹤和重現問題，從而提高整體安全性。借助最新的審計跟蹤，組織可以降低不必要的更改的風險，并在投入生產之前對其進行更正。
GitOps 方法的目標和優勢顯而易見。通過將所需基礎設施和應用程序配置的定義存儲在 Git 存儲庫中，團隊將擁有在結構化且安全的存儲部署應用程序所需的一切。如果出于災難恢復或復原能力的原因需要將應用程序重新部署到新位置，則可以輕松自信地執行此操作。此外，GitOps 模型將幫助組織在生產過程中通過各個測試階段推進應用程序。此過程需要將應用程序部署到不同的群集或群集中的不同命名空間，而 GitOps 模型確保可以完全、可靠且自信地完成此操作。
基礎設施和應用程序這兩個域之間有明顯的區別，組織的不同團隊負責每個領域。基礎設施配置負責 Kubernetes 平臺的定義和交付，包括計算節點、基于角色的訪問控制、治理策略以及創建應用程序可以運行的平臺的許多其他屬性。應用程序可以分段為編譯為容器映像中的可執行文件的源代碼組件，以及在特定環境中配置容器映像的 Kubernetes 資源。
GitOps 工作流
若要開始使用 GitOps，需要能夠以聲明方式管理的基礎設施。正因為如此，GitOps 通常被用作 Kubernetes 和云原生應用程序開發的模型，并且與Kubernetes實現持續部署。
CI/CD 管道通常由外部事件觸發，例如將代碼推送到存儲庫。在 GitOps 工作流中，使用拉取請求（pull request）進行更改，這些請求修改 Git 存儲庫中的狀態。批準并合并更改后，它們將自動應用于實時基礎設施。開發人員可以繼續使用其標準工作流和 CI/CD。
當將 GitOps 與 Kubernetes 一起使用時，自動化同步的實現通常是 Kubernetes Operator。Operator 將存儲庫中的所需狀態與已部署基礎設施的實際狀態進行比較。每當發現實際狀態與存儲庫中存在的狀態之間存在差異時，將更新基礎設施。還可以監視容器映像存儲庫，并以相同的方式進行更新以部署新映像。
GitOps 工作流可以提高生產力以及開發和部署的速度，同時提高系統的穩定性和可靠性。
總結
GitOps 和 DevOps 有一些相同的原則和目標。DevOps 是關于文化變革的，并為開發團隊和運維團隊提供了一種協同工作的方式。GitOps 提供了采用 DevOps 實踐（如協作、CI/CD 和版本控制）的工具和框架，并將其應用于基礎設施自動化和應用程序部署。開發人員可以在他們的代碼庫中工作，而 Operator 可以將其他必要的部分放置到位。在實踐中，逐漸形成了：
以DevOps理念為指導使用微服務開發應用基于容器化標準交付基于聲明式的基礎設施部署用git作為單一事實來源基于自動化的CI/CD最終演變為基于git的全流程CI/CD工作流框架，也即GitOps，實現敏捷價值交付。
