Argo CD 是一個實現 GitOps 的框架，他會透過 Git 儲存庫拉取資源。那 Git 要如何儲存管理這些內容 ? 如果將 Kubernetes YAML 存放在與應用程式程式碼分開的 Git 儲存庫中，有以下幾大優點：

1. 好的管理

• 職責分離，清楚知道此儲存庫的功能
• 工作流程分離，DevOps 團隊專注於 Kubernetes 或 Argo CD 相關配置，開發團隊專注程式碼開發

2. 安全性

• 存取限制，儲存庫嚴格管控存取，確保資訊不被洩漏
• 意外刪除，避免應用程式程式碼修改時異動了部署資源

3. 追溯性

• 獨立版控，輕鬆簡易更改歷史或回滾版本
• 獨立審查，因為職責分開，開發人員不用花額外時間看部署資源進行審查

4. 提高協同可塑性

• 並行開發
• 合併簡易

5. 部署策略單純

• 獨立部署，不用因為部署資源要異動，去牽連程式碼的儲存庫
• 靈活性，快速調整配置

6. 降低風險

• 易回滾，減少不同職責功能相互影響
• 提高可靠性，穩定運行

7. 更好的測試和驗證

• 獨立測試

根據以上，應用程式程式碼可使用任何分支策略，例如 GitFlow，因為它僅用於 CI。對於 Kubernetes YAML 儲存庫，用於 CD。當然根據不同組織規模和工具有不同策略。

1. Single branch (multiple directories)

--> Commit
|
O----Main----O----Main----O----Main----O

在單分支策略中，主分支始終會包含每個環境確切配置。理論上會有所有環境的默認配置，以及在單獨的環境特定目錄中定義的環境特定覆寫。單分支策略可以應用於 Kustomize 或是 Helm Chart 等工具。

2. Multiple branches

在多分支策略中，每個分支可相當於一個環境。這優點是每個分支將具有環境的確切部署 Kubernetes 資源，每個分支還將具有獨立的提交歷史記錄，以便在需要時進行追蹤和回滾。使用此方式基本上環境之間不會共享配置。對於 Kustomize 就不適用。

Multirepo 與 monorepo

對於較大團隊，擁有數十或數百名開發人員環境中，基本上會希望有多個儲存庫讓團隊可以彼此解耦，並且以自己團隊的速度運行。組織內的不同團隊將具有不同的程式碼發佈節奏和流程，如果使用單體配置儲存庫，一些功能可能完成數週，但需要等待預定的發佈。這將導致延遲將功能交付給最終用戶並發現潛在的程式碼問題，回滾也成一個問題，因為一個程式碼缺陷將需要回滾所有團隊的所有更改。

使用多儲存庫可依據功能進行組織，如果儲存庫是不同面向的可部署功能，那在團隊之間也許重組後，移動這些功能將更容易。

FROM www.cythilya.tw