Skip to main content

Multi-Organization DevOps Architecture

0. Introduction（導言）​

  • 本文件目標與適用範圍
  • 企業 DevOps 模板化的必要性
  • 多組織架構下的挑戰（Multi-Organization DevOps）
  • CI-driven vs GitOps 在企業內的定位

1. DevOps Template Overview（模板總覽）​

  • Template Repository 角色
  • Reusable Workflow / Composite Actions 的設計原則
  • 多語言（Java / Node / Python）支援方式
  • Multi-environment（dev/staging/prod）策略

2. Build Template（建置模板）​

2.1 Build 流程標準化的目標​

  • 確保所有服務能一致地 build
  • 抽離重複 YAML

2.2 各語言建置模板​

  • Java Build Template
  • Node.js Build Template
  • Python Build Template
  • Docker build + metadata 產生策略

2.3 安全性考量​

  • 無需暴露 Kubernetes 權限
  • 最小權限使用（GitHub OIDC / registry scope）

3. Scan Template（安全掃描模板）​

3.1 SCA（Dependency Scan）​

  • Snyk Template
  • Trivy Filesystem Scan
  • License Scan（optional）

3.2 Container Image Scan​

  • Trivy Image Scan
  • Snyk Container Scan
  • Container signing（cosign）

3.3 IaC / Kubernetes Scan（optional）​

  • KubeSec
  • Checkov
  • tfsec

3.4 審計與報告輸出（SARIF）​

  • GitHub Security Alerts 整合

4. Code Review Template（程式碼審查）​

4.1 Pull Request Template​

4.2 Commit Message Conventions​

4.3 Required Status Checks​

  • unit test
  • lint
  • SCA
  • CodeQL
  • build

4.4 Branch Protection 設計​

4.5 CODEOWNERS 與 Approver 模式​

5. Template Release Strategy（Gitflow / Versioning）​

5.1 Template 發行模式​

  • Reusable workflow 版本化
  • Tag versioning (v1, v1.1, v2)
  • Multi-version coexistence

5.2 Gitflow for Template Repository​

  • develop → main → tag
  • hotfix flow
  • 變更通知方式

5.3 Template Breaking Change 流程​

  • 避免破壞既有服務
  • 多 tag 維護策略

6. Multi-Organization Template Usage（跨組織模板使用模式）​

6.1 架構挑戰：多 Org Workflow 問題​

6.2 使用 Reusable Workflow（最佳作法）​

  • org1/platform-templates
  • org2/service repo 使用方式

6.3 Secret 與權限​

  • organization-level secrets
  • GitHub Enterprise 設定
  • 安全性邊界

6.4 Template Repository vs Project Template Repository​

  • skeleton project template
  • pipeline template

7. Deployment Strategy（部署策略）​

7.1 CI-driven Deployment（你現有的模式）​

  • manifest repo
  • 目錄區分環境
  • build → update YAML → auto commit → kubectl apply
  • 審計能力
  • 誰能影響部署

7.2 CI-driven Model：優缺點​

  • 優點：簡單、可審計、易落地
  • 缺點：CI 擁有 K8s 權限、攻擊面大

8. GitOps Deployment Strategy（GitOps 策略）​

8.1 Pull-based Deployment​

8.2 GitOps Controller（ArgoCD / Flux）角色​

8.3 模式差異：CI-driven vs GitOps​

  • 部署者
  • RBAC 边界
  • drift detection
  • 審計模式

8.4 GitOps Sync Policy​

  • 手動 sync
  • 自動 sync
  • prune 風險
  • 避免 destructive 行為

8.5 GitOps 風險與維運成本​

  • agent 掛掉的影響
  • 需要監控 controller

8.6 多組織 GitOps 架構​

  • 單一平台 GitOps repo
  • 多環境管理方式
  • 權限隔離

9. Cross-Organization GitOps Strategy（跨組織 GitOps 策略）​

9.1 多組織 GitOps 風險​

9.2 GitOps Repo 放置策略​

9.3 多 repo → GitOps repo PR 流程​

9.4 Image Promotion Strategy​

  • dev → staging → prod
  • tag-based
  • PR-based
  • ChatOps-based

9.5 RBAC 與權限隔離​

  • Kustomize path 隔離
  • deployer SA
  • CI 無需 cluster 權限

10. Best Practices（最佳實務）​

  • Template 異動流程
  • SCA + Code Review 整合
  • 多環境版本控管
  • 避免 prune 誤刪
  • GitOps 健康度監控
  • Version migration guide

11. Architecture Diagrams​

  • CI-driven Deployment Flow
  • GitOps Deployment Flow
  • Multi-Org Template Architecture
  • Role & Permission Boundary Diagram
  • Template Release Lifecycle