05 · 進階 CI/CD 與 GitOps 引擎
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 14 · 宣告式 GitOps 持續部署(CD) | ||||||||
| 14.1 | ArgoCD 由 Git 收斂、接上 SSO，並關閉手動 sync | 2026-09-01 | 2026-11-27 | 進行中 | — | SRE · 平台工程 | — | — |
| 14.2 | 平台元件由 ArgoCD 收斂，不再手動套用 | — | 2027-05-21 | 規劃中 | 14.1 | SRE · 平台工程 | — | 等待 14.1 |
| 14.3 | 單一應用的部署由合併或目錄動作觸發，不再由人執行 | — | 2027-11-19 | 規劃中 | 14.2, 22.2 | SRE · 平台工程 | — | 等待 14.2, 22.2 |
| 14.4 | 叢集內容可僅由 Git 重建 | — | 2028-03-10 | 規劃中 | 14.3 | SRE · 平台工程 | — | 等待 14.3 |
| 15 · CI/CD 管線最佳化 | ||||||||
| 15.1 | Kubernetes 上的漸進式發布，含自動回滾 | — | 2027-07-16 | 規劃中 | 14.1, 21.3 | SRE · 平台工程 | — | 等待 14.1, 21.3 |
| 15.2 | 以 APISIX 權重分流把流量從 VM 切到 Kubernetes | 2026-09-15 | 2026-12-31 | 進行中 | — | 平台工程 | — | — |
| 15.3 | 管線遷移至 GitLab CI，Jenkins 退場 | — | 2028-05-19 | 規劃中 | 15.1 | SRE | — | 等待 15.1 |
| 15.4 | 產出物於建置時簽章，部署前驗證 | — | 2028-09-08 | 規劃中 | 15.3, 32.6 | SRE · 平台工程 | — | 等待 15.3, 32.6 |
| 15.5 | 應用叢集上的第一次 canary 發布 —— goods API | 2026-11-12 | 2027-03-21 | 規劃中 | — | 平台工程 | — | — |
| 15.6 | 遷移上 Kubernetes 的服務預設以 canary 發布 | 2027-01-01 | 2028-02-25 | 規劃中 | 15.5 | 平台工程 | — | 等待 15.5 |
| 32 · 統一套件管理 | ||||||||
| 32.1 | Nexus 盤點與概念驗證定案 | 2026-10-12 | 2027-01-15 | 規劃中 | — | SRE | — | — |
| 32.2 | Repository、身分與私有連線納入 IaC | — | 2027-03-21 | 規劃中 | 32.1, 4.1 | SRE | — | 等待 32.1, 4.1 |
| 32.3 | 保留策略與 registry 端掃描上線 | — | 2027-05-21 | 規劃中 | 32.2 | SRE | — | 等待 32.2 |
| 32.4 | 歷史套件複製完成 | — | 2027-07-16 | 規劃中 | 32.2 | SRE | — | 等待 32.2 |
| 32.5 | 試點 pipeline 切換、新舊並行 | — | 2027-07-16 | 規劃中 | 32.2 | SRE | — | 等待 32.2 |
| 32.6 | 所有 pipeline、開發機與主機完成切換 | — | 2028-01-14 | 規劃中 | 32.4, 32.5 | SRE | — | 等待 32.4, 32.5 |
| 32.7 | Nexus 退場，僅保留最小化 NuGet | — | 2028-05-19 | 規劃中 | 32.6 | SRE | — | 等待 32.6 |
細節
14.1ArgoCD 由 Git 收斂、接上 SSO，並關閉手動 sync2026-11-27進行中 · 1/4
- ArgoCD 已安裝並開始收斂首批工作負載負責人 · Charles
- Repository 結構與 app-of-apps 結構議定負責人 · TBD什麼放在哪個 repository,決定了誰可以不經詢問就改動什麼。等幾十個應用都建好才決定,就得把它們搬一次。
- 以 Zitadel 接 SSO，RBAC 由群組對應負責人 · TBD
- 關閉手動 sync 與主控台變更;飄移只回報，不默默套用負責人 · TBD一個會收斂、卻仍接受手動變更的引擎,等於第二條路徑,而兩者恰好會在最要緊的時候分歧。與 7.3 對網路設備訂下的規矩相同。
14.2平台元件由 ArgoCD 收斂，不再手動套用2027-05-21規劃中 · 0/4
- 平台元件於 Git 宣告，由 ArgoCD 收斂負責人 · TBD
- 記錄 Terraform 與 ArgoCD 的分界:叢集在下，內容在此負責人 · TBD項目 04 佈建叢集;ArgoCD 收斂叢集裡跑的東西。是分層,不是兩套工具搶同一批物件。
- 21.1 重建的 DefectDojo 即為其中一個元件負責人 · TBD21.1 已經要求 Helm/GitOps manifest 與先建後拆的切換;本里程碑是它的落點,而不是另做一次。
- 叢集 bootstrap 可自 repository 重現負責人 · TBD
14.3單一應用的部署由合併或目錄動作觸發，不再由人執行2027-11-19規劃中 · 0/5
- Kubernetes 上的應用僅經由 ArgoCD 部署負責人 · TBD
- 有序的多系統發布為明訂的例外，由 23.1 驅動負責人 · TBD一次發布經常涵蓋二十多個必須依序上線的系統,而 ArgoCD 對每個應用各自收斂 — 它表達不了那個順序。因此順序留在 cogwork,而本里程碑只主張它做得到的事:單一應用,沒有人。
- 觸發來源是合併或 Backstage 目錄動作負責人 · TBD
- cogwork 不再觸發單一應用的部署負責人 · TBD目前 cogwork 直接呼叫 Jenkins job 進行部署 — 發布工單系統也是。Jenkins 退場讓兩者都改走 GitLab CI:cogwork 那一側由 23.2 承接,工單系統那一側由 24.3 承接。離開 cogwork 的是「觸發單一應用的部署」;推進一次有序發布仍留在它身上。本里程碑可被觸發的目錄動作來自 22.2,故相依於它。
- 把人從觸發環節拿掉,不能連「誰要負責」的答案也一起拿掉 — 那個答案移到了那次合併上。
14.4叢集內容可僅由 Git 重建2028-03-10規劃中 · 0/3
- 對空叢集執行收斂演練負責人 · TBD把 2.4 的從零重建模式套到叢集上:不接觸運行中的叢集,僅憑 repository 重建 — 這才讓 GitOps 從部署便利變成復原能力。
- 無法重建的部分予以記錄，而非默默手動補上負責人 · TBD缺口才是這次演練的產出。邊跑邊手動補起來的演練,只證明了當時有人在場。
- 記錄復原時間並發布 runbook負責人 · TBD
15.1Kubernetes 上的漸進式發布，含自動回滾2027-07-16規劃中 · 0/4
- Ambient 已於 11.1 隨 L3 模式叢集安裝,因此本里程碑是在既有的資料路徑上加上發布策略,而非另建一套。
- 推進與否由指標決定，而非有人盯著儀表板負責人 · TBD靠人盯著的 canary,只在上班時間有效,而且只在注意力持續的那段時間有效。
- 違反判準時自動回滾負責人 · TBD
- 政策檢查沿用 21.3 的發布閘門，不在此另建一套負責人 · TBD兩套閘門終究會分歧,屆時沒有人說得出該以哪一套為準。21.3 於 2027-02-12 完成,早於本里程碑,因此這是圖上真的畫得出來的依賴。
15.2以 APISIX 權重分流把流量從 VM 切到 Kubernetes2026-12-31進行中 · 1/4
- 由 APISIX 執行加權分流，位於 VM 與叢集之前負責人 · TBDKubernetes 那套工具搆不到 VM 工作負載，所以分流發生在它們前面，與用什麼部署它們無關。
- 分段切換 —— 1、5、10、50、100 % —— 每一段檢查錯誤率、延遲與 pod 狀態負責人 · TBD
- 回滾就是把權重調回去，且已演練過負責人 · TBD
- 記錄其為過渡：應用隨項目 26 遷移後即脫離此路徑負責人 · TBD不講明的話，過渡方案就會變成一套沒有人決定要建、卻永久存在的第二發布系統。
15.3管線遷移至 GitLab CI，Jenkins 退場2028-05-19規劃中 · 0/5
- 管線盤點，逐一標明負責人負責人 · TBD
- CI 走 GitLab CI、CD 走 ArgoCD — 拆開 Jenkins 原本跨的兩半負責人 · TBDJenkins 目前兩件事都做:建置與部署。退場不是換一套,而是換兩套,而這兩套的觸發來源不同。
- cogwork 改呼叫 GitLab CI，取代原本的 Jenkins job負責人 · TBD
- 測試平行化於重寫時一併完成，而非事後再做一輪負責人 · TBD每條管線都會被重寫一次。任何延後的事項,都意味著把它們全部再打開一次。
- Jenkins 確實關閉，而非留著運行負責人 · TBD留著的 Jenkins 是一條仍然可用的路,而仍然可用的路,會在新路第一次不方便時被用上。
15.4產出物於建置時簽章，部署前驗證2028-09-08規劃中 · 0/4
- 簽章寫在共用的 GitLab CI 範本，而非逐條管線各自實作負責人 · TBD在 15.3 重寫時一併做幾乎沒有成本;之後再做,就得把每條管線重新打開一次。
- 未簽章或無法驗證的產出物於部署時遭拒負責人 · TBD沒有人檢查的簽章只記錄了來源,卻沒有約束力 — 拒絕部署才讓它成為一道控制。
- 簽章金鑰置於 Vault 保管負責人 · TBD簽章不在項目 12 議定的消費者順序內(資料庫、應用程式 secrets、SSH),因此不與 12.x 建立依賴 — 這項要求在此以文字載明。
- 記錄與項目 20 的分界:簽章在此產生，於彼收集負責人 · TBD項目 20 建立涵蓋 provenance 與簽章的可搜尋稽核軌跡;它消費本里程碑的產出,而不自行產生。項目 20 沒有里程碑,故此界線只能是文字。
15.5應用叢集上的第一次 canary 發布 —— goods API2027-03-21規劃中 · 0/4
- 凍版期間（11/11 前）設計 canary 流程負責人 · TBD
- goods API Phase 11–12 在叢集自己的 gateway 上以 canary 發布負責人 · TBD
- 推進與回滾判準明訂：錯誤率與延遲，而非有人盯著負責人 · TBD
- 整理成 15.6 套用到每個遷移服務的範本負責人 · TBD
15.6遷移上 Kubernetes 的服務預設以 canary 發布2028-02-25規劃中 · 0/3
- 2027 起每一個遷上 Kubernetes 的服務都以 canary 發布負責人 · TBD
- canary 步驟寫進鋪好的路的範本，而非逐服務各自設定負責人 · TBD
- 不走 canary 的服務具名列出並寫明原因負責人 · TBD
32.1Nexus 盤點與概念驗證定案2027-01-15規劃中 · 0/8
- 列出每個 Nexus repository 的格式、大小與使用者（依存取紀錄）負責人 · TBD
- 從連外 proxy 紀錄盤點目前誰從哪個 registry 抓了什麼負責人 · TBD
- 每種格式端到端驗證 —— Docker、npm、Maven、PyPI、Go（含私有模組）、Apt 24.04／26.04 archive 與 security負責人 · TBD
- 經 Shared VPC 路徑的地端拉取，對照現行 mirror-nexus 路徑量測延遲、頻寬與 Apt 大量修補流量負責人 · TBD
- 確認 Artifact Analysis 的涵蓋範圍、費用與 DefectDojo 匯入負責人 · TBD
- 確認各格式的 virtual repository 支援度，以及組織政策能否限制 remote 上游負責人 · TBD
- 由各團隊確認試點服務負責人 · TBD
- 決策記錄定案 —— region、Go、地端拉取路徑、歷史複製範圍負責人 · TBD
32.2Repository、身分與私有連線納入 IaC2027-03-21規劃中 · 0/6
- 以同一個 Terraform module 建立各格式的 standard、remote、virtual repository；映像 repository 設為 immutable tags負責人 · TBD
- 上游只在 IaC 中定義 —— create／update 權限只給 Terraform 身分；virtual repository 以 internal 優先負責人 · TBD
- pipeline 以 workload identity federation 存取、只能寫自己的 repository；人員走 SSO；開啟資料存取稽核日誌負責人 · TBD
- 私有連線 —— 混合連線接在 Shared VPC host 專案、宣告 restricted VIP、地端 DNS 將 *.pkg.dev 指向 restricted VIP、VPC-SC 邊界涵蓋 host 與 GAR 專案負責人 · TBD
- 地端 Apt 快取，上游只有 GAR負責人 · TBD
- 錯誤率與儲存量告警接入監控平台，並設定成本預算負責人 · TBD
32.3保留策略與 registry 端掃描上線2027-05-21規劃中 · 0/4
- 清理政策先以 dry-run 執行，並與叢集上執行中的 digest 比對負責人 · TBD
- 版本 tag 永不清除；commit tag 保留最新 N 版、部署中者不清負責人 · TBD
- internal-docker 開啟 Artifact Analysis，結果送入 DefectDojo負責人 · TBD
- 每日重掃執行中的 digest負責人 · TBD
32.4歷史套件複製完成2027-07-16規劃中 · 0/3
- 映像依 digest 複製；Maven、npm、PyPI、Apt 套件重新發布負責人 · TBD
- 各 repository 的數量與 checksum 與 Nexus 一致負責人 · TBD
- 增量複製可重複執行，直到最後一條 pipeline 切換負責人 · TBD
32.5試點 pipeline 切換、新舊並行2027-07-16規劃中 · 0/3
- 試點切換 —— 本網站、api-gateway、一個 Maven 與一個 npm 服務（名單以 32.1 為準）負責人 · TBD
- 演練回退：把 registry URL 改回去負責人 · TBD
- 25.1 的 base image 發布至 GAR負責人 · TBD
32.6所有 pipeline、開發機與主機完成切換2028-01-14規劃中 · 0/7
- 所有 pipeline 改用 GAR，GitLab CI 與 Jenkins 皆同 —— 不等 15.3負責人 · TBD
- 退掉 mirror-nexus stage負責人 · TBD
- 開發機設定 —— 每種格式一個 URL、不用 --extra-index-url、不用 GOPROXY …,direct —— 附 SOP 與 Office Hour負責人 · TBD
- CI 擋下含 git 或 URL 相依的 lockfile負責人 · TBD
- 主機 Apt 來源改為地端快取，由 Ansible（4.4）推送負責人 · TBD
- 收斂連外 proxy 允許清單 —— 不再能直接連公開 registry 與 Ubuntu archive負責人 · TBD
- 完成最後一次增量複製後，Nexus 改為唯讀負責人 · TBD
32.7Nexus 退場，僅保留最小化 NuGet2028-05-19規劃中 · 0/3
- Nexus 唯讀並行至少四週後除役負責人 · TBD
- NuGet 實例最小化、納入 IaC 並有備份負責人 · TBD
- 記錄其退場條件 —— GAR 支援 NuGet，或該單位不再使用負責人 · TBD