架構師觀點: 你需要什麼樣的 CI / CD ?
摘要提示
- 工具迷思: 先問問題後選工具，別被流行的框架與關鍵字牽著鼻子走。
- 導入動機: CI/CD 是為了解決團隊效能與品質問題，不是為了履歷上的名詞。
- 漸進導入: 從最小可行流程開始，逐步擴大，避免一次到位導致失敗。
- 三大核心: 版本控制、自動建置與整合測試、發行管理是必須先顧好的三環。
- 成本與取捨: 優先善用既有工具與系統，降低學習與替換成本。
- Git Flow 精髓: 先把 master/develop 用好，再按需求逐步導入其他分支。
- CI 先求基本: 成功建置、通過單元測試、成品管理三件事先做好。
- CD 簡化策略: 先善用套件管理或容器化管理版本與相依性，逐步自動化。
- 安全價值: CI/CD 能避免私編產出直上線風險，完善追溯與控管。
- 架構先行: 先定義目標與流程架構，再填入工具，持續優化。
全文重點
作者以架構師視角，反思導入 CI/CD 與 DevOps 的常見誤區：太多團隊熱衷工具與名詞，而忽略要解決的核心問題。文中主張導入流程應從真實需求出發，循序漸進，避免一次到位。回顧早年以「Daily Build」土炮 CI 的經驗，雖然原始但已帶來關鍵價值：每天自動建置、早發現問題、可供團隊整合測試，證明「小步快跑」的有效性。
作者提出導入 CI/CD 的三大必備環節：第一，版本控制。把 source code 當資產管理，從開發到發行、hotfix、舊版問題追溯，都需在版控中被精準定位。第二，自動建置與整合測試（CI）。程式碼變更時自動建置、執行單元測試與品質檢查，讓團隊第一時間掌握風險。第三，發行管理（Release Management）。把 CI 成品透過規範流程部署到各環境，並依分支策略（如 develop 對應 BETA、master 對應 RTM/RC）制定發行規則。這三環是最低限制，無論工具選擇如何，都應優先落地。
在工具選擇上，作者強調優先整合與善用既有系統，減少學習與替換成本，避免「多個香爐多隻鬼」。例如在 GitLab、TFS、Jenkins 重疊場景下，決策收斂到 GitLab，以一套系統覆蓋版控、開發管理與 CI。版本控制流程建議參考 Git Flow，但不必教條化；先把 master/develop 用好，其餘 feature/release/hotfix 分支可視情況逐步導入，避免複雜度超前團隊能力。
CI 的導入先聚焦三件事：成功建置、單元測試通過、成品管理（artifacts）。對於尚未建立測試文化的團隊，建議新專案採 TDD、舊專案逐步補測，不必一次補齊；並把單元測試也當作範例、bug reproduce 與 API 規格驗證的工具。可透過 GitLab CI 的 pipelines 清楚掌握結果與通知。
CD 是最複雜的一環，不必強求一次全自動。可以先用套件管理（如 apt-get、npm、nuget）或容器化（Docker image + registry）來管理版本與相依性，將部署轉為「從可信任的包拉取與安裝」，把高風險的重複性人工步驟自動化，保留少量簡單不可自動化步驟。若無法容器化，暫時以檔案伺服器與明確版本規則（建議採 SemVer 2.0）過渡。
最後，作者以安全角度強調 CI/CD 的必要：若沒有流程控管，開發者可在本機偷偷編譯含惡意邏輯的二進位上線，既無法追溯也無法防堵。CI/CD 透過「來源即版控、建置即流水線、部署即產出包」杜絕此風險，亦利於稽核與責任歸屬。建議先定義簡化版的流程架構，將人工作為僅限提交程式碼，其餘由 CI/CD 產出可追蹤的發行包，並透過套件管理或 registry 統一發放，隨後再逐步擴充到完整體系。總結：目標先行、流程為本、工具輔助，小步快跑、持續優化，才是成功導入 CI/CD 的關鍵。
段落重點
抱怨
作者觀察到軟體圈存在嚴重的「工具/框架迷思」，面試時人人關心是否有版控、CI/CD、SCRUM，卻常缺少實作經驗；進到團隊後，落地流程又容易引發不必要的反彈。核心問題是許多人把名詞當目標，而非手段。對工程師而言，流程與工具應服務於效率與品質，而非成為自我標榜的清單。作者鼓勵自我驅動的學習：「用起來」才算掌握，例如把個人的部落格搬到 GitHub，實際操作 Git 與 Git Flow，從中體會 as code 的價值。對「我會很多工具」的說法，作者更在意能否用工具解決問題，因為工具學得來、思考與應用更關鍵。導入任何系統成本都很高，不宜輕易替換；除非明確不足或已掌握 80% 再升級，否則應優先「找對的人用好工具」，而非盲目追新。
「我是來學習的，你應該要教我才對啊!」
作者肯定學習動機，但認為應展現在行動上：主動找機會實作、把日常工作版控化、用 GitHub Pages 實作部落格，強迫自己練習與沉澱。這樣的歷程能深化理解，也能建立 as code 的意識，讓流程化、自動化變得自然。作者分享將 Blog 轉為 GitHub Pages 的案例，說明在實務中以工具支撐流程的好處：可追蹤、可再現、可協作。
「我會 XXX + ZZZ 框架，還有 AAA + BBB 系統…」
作者指出「會工具」不等於「能解題」，後者遠比前者重要。導入系統需審慎評估成本，替換更要謹慎。長期原則是：若現有系統未爛到無法滿足關鍵需求，或未被團隊駕馭到足夠程度，不應輕易更換。更應相信「找對人善用工具」。這樣的態度能避免頻繁遷移造成的生產力衝擊，並促進團隊在既有基礎上持續精進。
我想要什麼樣的 CI / CD ?
釐清：對於從零開始或經驗不足的團隊，網路上的成功案例常看似遙不可及。導入關鍵不在於先選哪套工具，而是先定義你要解決的問題與第一步該做什麼。作者將焦點放在「最小可行流程」：能符合當下需求、具擴充性與未來性，之後再逐步加料。先確立落地與價值，再追求完整。
多年前 (2003) 土炮 Daily Build 流程的經驗
作者分享 2003 年用 VSS+Virtual PC 自製「Daily Build」的經驗：每天半夜還原 VM、抓最新版原始碼、執行建置與部署到本機 IIS，再做簡單自動化測試，隔天團隊即可用於整合測試與取用 Build。雖然粗糙、僅能排程、建置失敗修復不易，但它提供了最關鍵的價值—每天確知能否成功編譯與基本可用，證明即使簡化的自動化也足以顯著降低風險與溝通成本，是可複製的導入起點。
最精簡的 CI / CD 流程
導入時，先顧好三大關鍵：版本控制、自動建置與整合測試、發行管理。版本控制不只是記錄變更，更要能精準追蹤到任一發行版本的原始碼；CI 要在程式變更時第一時間給出建置與測試的品質訊號；發行管理要把 CI 成品依規則部署到各環境，並與分支策略對應（如 develop→BETA、master→RTM/RC）。對於白紙團隊，建議先確保這三環節都能產生實際效益，再談高階做法或工具切換，逐步擴張而非一口氣到位。
精簡既有的系統與工具組
在已擁有多套工具（如 GitLab、TFS、Jenkins）卻用得零散的情況下，優先精簡與整合，降低學習與遷移成本。作者的決策是收斂到 GitLab 一套系統，涵蓋版控、開發管理與 CI，以滿足未來數年的需求。核心原則：少即是多，減少重疊與維護負擔，讓團隊心智負擔降到最低，導入阻力亦隨之下降，流程成效更易顯現。
版控的流程 - Git Flow
建議以 Git Flow 為參考架構：master 與 develop 永久存在，其餘 feature/release/hotfix 為短期分支，任務完成即刪除。若團隊經驗不足，先把 master/develop 用好即可，其他分支依需求循序導入。重要提醒：決定取捨的人需先徹底理解 Git Flow，否則容易把關鍵環節誤砍，導致流程變形與災難。光是把 master/develop 用紮實，即使尚未導入 CI/CD，也已能顯著優於多數團隊。
持續整合 - GitLab CI
CI 導入先聚焦三點：成功建置（success build）、通過單元測試（pass unit test）、成品管理（manage artifacts）。任一 push 觸發 CI，先確認能建置、再跑測試，最後將產出統一管理並可供後續 CD 使用。對單元測試的策略：新專案採 TDD，舊專案不必一次補齊，先建立流程並逐步累積。單元測試同時可作為使用範例、bug reproduce 與 API 合規驗證。GitLab pipelines 能清楚呈現結果與通知，是推動團隊建立信心的重要工具。
持續部署 - Package Management
CD 複雜度高，先求「能用且穩」：可採半自動，優先自動化高重複、易出錯步驟。推薦充分利用套件管理（apt-get、npm、nuget 等），以版本規則（建議 SemVer 2.0）與相依控管降低風險。若是網站與服務，強烈建議容器化，將部署統一為「推送/拉取 image + registry」的模式，本質上就是專用套件管理；若短期無法容器化，可先用檔案伺服器過渡。關鍵在於把「產出可追溯的包」建立起來，使部署變得可復現、可稽核、可回滾。
結論: 執行架構與方向
成功導入 CI/CD 的關鍵是「架構先行，工具其後」。先定義簡化版流程：開發者只需把程式碼 push 到版控，其餘由 CI/CD 產出受控的發行包，統一透過套件管理或 registry 提供給開發、測試與上線使用。之後再逐步擴張到完整流程。此模式同時強化資安與可追溯性：避免開發者在本機私編直上 production 的風險，所有產出均有來源、可查證、能回滾。從最小可行流程開始，小步快跑、持續優化，聚焦解決問題與長期效益，而非追逐工具清單，才是團隊導入 CI/CD 的正確道路。
資訊整理
知識架構圖
- 前置知識：
- 版控基本觀念與操作（Git、commit、branch、merge）
- 軟體建置與測試基礎（build、unit test、artifact）
- 基本發行與版本概念（release、hotfix、SemVer）
- 自動化與流程思維（CI/CD、Pipeline）
- 套件管理與容器基礎（npm/nuget/apt，Docker/Registry）
- 團隊流程與變更管理（漸進導入、成本/學習門檻）
- 核心概念（3-5 個）：
- 工具次之，需求與流程優先：先定義要解決的問題，再選工具；避免「工具控」心態
- 最小可行 CI/CD：三大必備環節—版本控制、持續整合（build+unit test+artifact）、發行管理
- 精簡版 Git Flow：先用 master/develop，視需求再引入 feature/release/hotfix
- 以套件管理與容器簡化 CD：先把成品進套件庫/Registry，再逐步自動化部署
- 逐步導入、善用現有系統：減少學習成本，提升導入成功率與資安可追溯性
- 技術依賴：
- Source Control -> CI（build/test）-> Artifact/Package Registry -> CD/Deployment
- Unit Test/TDD 依賴可測設計與測試框架
- Container 化 CD 依賴 Dockerfile、Image、Registry，必要時再接編排系統
- 通知/看板依賴 CI 伺服器（如 GitLab Pipelines）與整合
- 應用場景：
- 從零開始的開發團隊需要「最低可行 CI/CD」
- 既有工具雜亂（GitLab/TFS/Jenkins/Redmine 重疊）需整併精簡
- 舊專案缺測試先建流程、再逐步補測
- Web/Service 導入容器化與 Registry 管理版本
- 需要資安與可追溯（避免「開發者本機 build 上線」）的組織
學習路徑建議
- 入門者路徑：
- 先學 Git 基礎與簡化 Git Flow（只用 master/develop）
- 建立最小 CI：成功編譯、執行單元測試、產出 artifact
- 將成品推送到套件庫或簡單的檔案伺服器；導入 SemVer 命名
- 使用 CI 介面觀察 pipeline 與通知（先學會讀燈號）
- 進階者路徑：
- 擴充 Git Flow（feature/release/hotfix）、分支保護、Code Review
- 系統化單元測試策略，bug reproduce test、API 規格驗證
- 引入套件管理與私有 Registry；逐步容器化關鍵服務
- 精簡/整併工具鏈（如集中到 GitLab），規劃權限與審計
- 實戰路徑：
- 建立從 commit 到 package registry 的端到端流水線
- 半自動部署：人為審核 + 一鍵部署腳本；逐步走向全自動
- 度量指標（build 成功率、測試覆蓋率、平均修復時間）與資安檢核（來源可追溯）
- 針對團隊路線圖分階段導入，定期回顧調整流程
關鍵要點清單
- 需求優先於工具：先釐清要解決的痛點，再選擇系統與框架（優先級: 高）
- 最小可行 CI/CD：先做到版控、成功編譯、單元測試、成品管理（優先級: 高）
- 版本控制即資產管理：能精確追溯任何發行版對應的程式碼（優先級: 高）
- 精簡 Git Flow 起步：先穩定運作 master/develop 再擴充（優先級: 高）
- 善用既有工具：整併重疊系統以降低學習與維運成本（優先級: 中）
- Pipeline 成果可視化：透過 CI 介面與通知提升團隊回饋速度（優先級: 中）
- 單元測試策略：新專案 TDD、舊專案先建流程再逐步補測（優先級: 高）
- 測試多重價值：範例用法、bug reproduce、API 規格驗證（優先級: 中）
- 成品與套件管理：使用 SemVer 與私有套件庫統一管理 artifacts（優先級: 高）
- 容器化優先 CD：以 Docker + Registry 作為網站/服務的發行媒介（優先級: 中）
- 半自動到全自動：先移除高風險重複人工步驟，再逐步全自動（優先級: 中）
- 資安與可追溯：禁止本機 build 直上，所有部署來源來自 CI/CD（優先級: 高）
- 分支與發行規則：不同分支對應不同發行節點（develop=beta、master=RC/RTM）（優先級: 中）
- 工具整合一體化：以 GitLab 類平台統包版控/CI/Issue/看板提升一致性（優先級: 中）
- 漸進式導入與變更管理：分階段落地，降低阻力並確保每步有成效（優先級: 高）
