架構師觀點: 你需要什麼樣的 CI / CD ?

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是 CI（持續整合）？

• A簡: 持續整合是對每次程式碼變更自動進行建置與測試，快速回饋品質狀態，降低整合風險，讓團隊及早發現問題。
• A詳: 持續整合（Continuous Integration, CI）是一種工程實務：當開發者提交（push/merge）程式碼變更時，自動觸發從建置（compile/build）到測試（單元測試、靜態檢查）的流程，盡早暴露整合問題。它強調小步快跑、頻繁整合、快速回饋，藉由一致的機器環境與腳本，減少「在我機器可以跑」的情況。常見輸出包含測試報告、建置成品（artifacts）與狀態徽章，便於追蹤與度量。CI 的價值在於建立穩定、可重複的品質閘道，讓團隊專注開發，降低修復成本，並為後續的 CD 奠定基礎。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, A-Q12, B-Q1

A-Q2: 什麼是 CD（持續交付/部署）？

• A簡: 持續交付/部署將已通過 CI 的成品一致地發佈到各環境，盡可能自動化，縮短交付週期，提升可預測性與安全性。
• A詳: 持續交付（Continuous Delivery）著重於讓每個變更都能隨時處於可發佈狀態，透過自動化程序包裝、簽署、驗證成品，並準備好交由人工核准上線；持續部署（Continuous Deployment）則更進一步，將核准也自動化。文章建議初期採「半自動」CD：用套件管理（如 apt、npm、nuget、容器 Registry）統一管理版本與相依性，降低人工部署錯誤，逐步過渡至全自動。CD 的核心是可重複、可追溯、可審計的發行機制，將部署與人為風險解耦，讓組織更敏捷且更安全。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, A-Q13, A-Q14, B-Q10

A-Q3: 什麼是 DevOps？

• A簡: DevOps 是開發與運維的協作文化與實踐，透過自動化與共享責任，加速交付、提升品質與可靠性。
• A詳: DevOps 不只是工具，而是一套跨職能的文化、流程與技術實踐。其核心包括共用目標、持續回饋、自動化、可觀測與責任共擔。搭配 CI/CD、版本控制、監控與基礎設施自動化，DevOps 讓軟體從需求到上線的流程縮短、風險降低。文章提醒：不要在不了解要解決的問題前就「工具先行」。應從痛點出發，以最小可行流程（版控、CI、發行管理）逐步擴展，讓 DevOps 成為落地的工程方法，而非流行口號。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, A-Q5, B-Q8

A-Q4: 為什麼不要「工具先行」？

• A簡: 工具是手段非目的。先釐清問題與目標，再挑工具；避免被工具牽著走，導致複雜、成本高、成效差。
• A詳: 文章批判「工具控」心態：在不清楚問題與目標前盲目追逐熱門工具與框架，常導致過度設計、操作負擔與學習曲線，最後難以落地。正確做法是：先定義要解決的問題與成功指標（如可追溯、可重複、品質可視），再以最小可行流程與團隊可承受的學習成本導入，並保留擴充性。亦應評估現有工具是否可滿足需求，能整併就整併，避免多套重疊帶來的治理成本。工具服務於目標，人才駕馭工具，這才是持久之道。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q18, B-Q12, C-Q7

A-Q5: 團隊為何需要 CI/CD？

• A簡: CI/CD 提供快速回饋、可重複與可追溯的交付流程，降低整合與部署風險，提升效率與資安。
• A詳: 導入 CI/CD 能把「建置、測試、打包、發行」自動化與標準化，讓每次變更都有一致品質門檻與可審計紀錄。CI 及早發現整合問題，CD 確保可重複部署並縮短交付週期；artifact 與版本策略使追溯與回滾清晰。文章強調資安價值：避免開發者用本機 build 直接上線，杜絕難追查的風險，將部署權限與來源收斂到 CI/CD 產物與管道。對新團隊，更能在低門檻下逐步建立工程紀律。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q20, B-Q11, D-Q6

A-Q6: 版本控制的核心價值是什麼？

• A簡: 追蹤變更、分支協作、追溯來源與發布版號對應，讓開發、維運與問題診斷都有依據與秩序。
• A詳: 版本控制（如 Git）不僅保存誰改了什麼，更支援分支策略（開發、發行、修補）、合併紀錄、標籤與權限治理。文章強調它是軟體資產的管理骨幹：從開發中版本、上線版本，到日後 hotfix 或舊版問題重現，都需能「精確定位」到源碼與對應成品。藉由 commit SHA、標籤與分支策略（如 Git Flow），建立「條碼式」可追溯性，讓 CI/CD 鏈條完整，為品質與資安提供事後可審計的事實依據。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q9, A-Q10, B-Q14

A-Q7: 何謂發行管理（Release Management）？

• A簡: 以規範化流程將 CI 產物部署到各環境，管理版本、渠道與核准，確保可重複與可審計。
• A詳: 發行管理涵蓋從 CI 成品（artifacts）到環境（開發、測試、正式）的整套部署流水線，包括版本編碼（SemVer）、標籤、核准點與變更審核。文章建議初期先建立「分支→發行通道」規則（如 develop→Beta、master→RC/RTM），並善用套件管理或容器 Registry 做為統一產物來源。當全自動尚未成熟，可採半自動：自動化打包與上傳、人工簡單部署，逐步擴大自動化覆蓋率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, A-Q13, B-Q10

A-Q8: CI 與 CD 有何差異？

• A簡: CI 著重建置與測試的自動化回饋；CD 著重將合格成品穩定發佈到環境，管理版本與部署。
• A詳: CI（持續整合）聚焦「變更一發生就驗證」，包含編譯、測試、掃描，確保主幹健康；CD（持續交付/部署）聚焦「把合格成品可靠地送達」，包含打包、標籤、發佈與部署策略。兩者相輔相成：CI 產出可部署的 artifacts 與證據（測試報告），CD 以規則與自動化將它們推進各環境。文章建議起手式：先把 CI 做到位，再以套件管理/容器化簡化 CD，逐步走向全自動。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, B-Q8, B-Q10

A-Q9: 什麼是 Git Flow？

• A簡: Git Flow 是一套分支模型，定義開發、發行、修補的分支與流程，協助團隊有序協作與版本管理。
• A詳: Git Flow 定義 master（穩定釋出）與 develop（開發）為長存分支，並以 feature、release、hotfix 為短期分支支撐需求開發、發行準備與緊急修補。它藉由明確的分支邏輯與合併節點，讓功能隔離、版本準備與緊急修補互不干擾。文章建議新手團隊先把 master/develop 用好，其餘短期分支視成熟度逐步導入，避免因過早複雜化而失敗。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q11, B-Q2

A-Q10: Git Flow 中哪些分支是長期存在的？

• A簡: master 與 develop 為長期分支；feature、release、hotfix 為短期任務性質，用畢合併後即刪除。
• A詳: 在 Git Flow 模型裡，master 代表已釋出的穩定線，develop 代表持續整合的開發線，兩者長存。feature 分支用於新功能研發，完成後併回 develop；release 分支用於出版本準備（修瑕疵、提升穩定），併回 master 與 develop；hotfix 用於緊急修補，從 master 分出，完成後同時回併 master 與 develop。此設計在清楚責任邊界的同時，避免長期漂移與分支污染。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q9, B-Q2, C-Q2

A-Q11: 為何建議先從 master/develop 開始？

• A簡: 先掌握主幹與開發線可大幅降低複雜度，快速建立秩序與可追溯，再逐步引入其他短期分支。
• A詳: 許多團隊在一開始就全套導入 Git Flow 會因流程繁複、經驗不足受挫。文章建議先把長存分支（master、develop）的保護、合併規則與釋出對應建立好，快速收斂混亂與降低學習成本。當團隊熟悉分支紀律與 CI 後，再逐步導入 feature/release/hotfix 分支，讓流程自然演進，兼顧擴充性與成功率。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q2, B-Q10, A-Q9

A-Q12: 什麼是建置成品（Artifacts）管理？

• A簡: 將建置輸出物集中保存、版本化與可追溯，供後續測試、部署或他專案重用，避免重複建置。
• A詳: Artifacts 是 CI 產出的可交付物，如二進位檔、壓縮包、測試報告等。妥善管理意味著：命名與版本策略（含 commit SHA）、集中儲存（Artifact 庫或套件管理）、保留期限與權限控管。文章強調「manage artifacts」是最小 CI 的關鍵之一，讓 CD 可直接取用，不需重建，並建立來源可追溯的供應鏈。對多環境發布與快速回滾尤為重要。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q14, C-Q1

A-Q13: 套件管理在 CD 中扮演什麼角色？

• A簡: 套件管理統一版本與相依性，做為部署唯一來源，簡化流程並降低人工錯誤與不一致。
• A詳: 無論是 apt、npm、nuget 或容器 Registry，套件管理皆提供版本索引、相依性解析、權限與稽核。文章建議將 CD 簡化為「CI → 發佈到套件庫 → 各環境安裝部署」，即便暫時手動，也因來源一致且可追溯而風險大降。再配合 SemVer 與渠道（Beta/RC/RTM）標記，OP 與開發能清晰選版與升級，逐步演進到全自動部署。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q4, B-Q5, C-Q4

A-Q14: 為何容器化能簡化部署？

• A簡: 容器將應用與依賴封裝為映像，搭配 Registry 做版本管理，跨環境一致，部署與回滾更可靠。
• A詳: 容器將系統依賴、執行期與應用整合封裝為不可變映像（image），透過 Docker Registry 管理版本與標籤。文章指出，對於網站、服務、工作程序等，容器是一致的打包格式，即是「套件管理」。其帶來一致性（避免環境差異）、快速啟動、易於回滾與可追溯。對於尚未能全自動 CD 的團隊，也能先用「建 image、推 Registry、環境拉取」的半自動流程，逐步演進。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, C-Q5, C-Q9

A-Q15: 什麼是 SemVer？為何建議採用？

• A簡: SemVer 是語意化版本規範，以主版.次版.修訂與預發布標記表達變更幅度，提升可預測性。
• A詳: Semantic Versioning（SemVer）以 MAJOR.MINOR.PATCH 表示不相容變更、新功能相容變更與相容修補，並支援預發佈標記（如 -beta, -rc）。文章建議搭配 Beta/RC/RTM 渠道明確管理預發佈與正式版。採用 SemVer 有助於下游（部署、相依專案）理解升級風險、制定自動升級策略與回滾，並與套件管理、容器標籤自然整合，強化整體供應鏈清晰度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, C-Q3, A-Q13

A-Q16: 什麼是「Daily Build」？

• A簡: 固定排程自動建置與測試的早期 CI 形式，雖無事件觸發，但能及早掌握整合健康度。
• A詳: 在現代 CI 普及前，Daily Build 指以排程（如半夜）自動從版控取最新碼、建置、部署至開發伺服器，並執行基本測試。文章分享 2003 年以 VSS＋虛擬機土炮 Daily Build 的經驗，雖僅每日、回饋慢且維護難，但已能在隔天知悉建置健康與版本狀態。對於尚無事件觸發能力的舊工具（如 VSS），Daily Build 是可行的起步。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q16, D-Q10, A-Q1

A-Q17: 為何導入 CI/CD 要循序漸進？

• A簡: 一次到位易失敗。先建立最關鍵三環：版控、CI、發行管理；再逐步擴展，兼顧效益與可承受度。
• A詳: CI/CD 涉及流程、工具與文化變革。文章指出：從零起步若追求「大全套」，易因學習曲線、環境複雜度與反彈而失敗。正確策略是選擇兼顧完整與擴充性的藍圖，但先只導入精華（版控、CI 的 success build/單元測試/成品管理、基本發行策略），讓每階段都可見成效，再按需擴展。此法能降低風險、積累信心並讓團隊逐步內化新習慣。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q8, C-Q1, C-Q9

A-Q18: 為何應整併功能重疊的工具？

• A簡: 多套系統增加學習與維運成本。整併到足夠用的一套（如 GitLab）可降阻力、提效與一致性。
• A詳: 團隊常同時使用 GitLab、TFS、Jenkins、Redmine 等多套重疊工具，導致流程割裂、維護與整合成本升高。文章主張優先善用既有工具並整併到能滿足需求的單一平台（如 GitLab 同時具版控、開發管理、CI），降低學習門檻與反彈，避免遷移成本與治理負擔。唯有在確定原工具無法滿足關鍵需求時才考慮替換，讓人與流程價值優先於工具堆疊。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, C-Q7, A-Q4

A-Q19: 單元測試在 CI 的價值是什麼？

• A簡: 單元測試讓變更可驗證、可回歸。除測試外也充當範例、規格與缺陷重現，提升品質可視性。
• A詳: 單元測試（含 TDD 思維）在 CI 中是品質閘道：每次變更都需通過，避免缺陷進入主幹。文章建議新專案採 TDD，舊專案先建立流程再漸進累積測試，避免一次性補測的形式主義。此外，測試可作為函式庫使用範例、API 規格的執行化描述，遇到回報缺陷時以測試重現與防止回歸。這些附加價值讓 CI 的回饋可解釋、可維護。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q8, D-Q2

A-Q20: CI/CD 如何強化資安？

• A簡: 將建置與部署收斂到管控的流水線，禁止本機直上，所有產物可追溯、可稽核，降低惡意與疏失風險。
• A詳: 文章舉例：若開發者本機偷偷加入後門並直接上線，難以從版控追查。導入 CI/CD 後，部署只允許來自 CI 產物庫或 Registry，並以分支與核准控制渠道；成品帶有 commit SHA、簽章與紀錄，建立可追溯供應鏈與最小權限。此舉同時降低「人為操作」與「來源不明」風險，讓資安議題具體可衡量，也更容易獲得管理層支持。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, D-Q6, A-Q12

A-Q21: 什麼是 Pipeline？

• A簡: Pipeline 是自動化步驟的有序集合，如建置、測試、打包、發佈，並提供狀態、日誌與產物。
• A詳: 在 CI/CD 平台（如 GitLab CI），Pipeline 由多個階段（stages）與作業（jobs）組成，定義從變更觸發到產物輸出的完整路徑。它記錄每一步的狀態、日誌與產物，提供 Web 介面、通知與 API 查詢。文章強調最小可行 Pipeline 應至少包含：成功建置、單元測試與產物管理，讓團隊能以同一視圖快速掌握品質與可部署性，並成為後續 CD 的穩固基座。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, C-Q1, A-Q22

A-Q22: CI 執行結果的回饋方式有哪些？

• A簡: 透過 Pipeline 頁面、電子郵件與行動 App 通知回饋狀態，並可用專案貼紙/徽章集中展示燈號。
• A詳: 平台通常提供多渠道回饋：Web Pipeline Dashboard 展示各階段狀態與產物；電子郵件向關注者推播結果；行動 App 即時通知變更。亦可用專案貼紙/徽章將多個專案的燈號集中在同一頁，方便跨專案掌握整體健康。這些回饋縮短迴路、促進責任共擔，讓問題能第一時間被看見與處理，支撐持續改進。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, C-Q10, A-Q21

A-Q23: 何時允許半自動的 CD？

• A簡: 當全自動過於困難或昂貴時，保留少量簡單人工步驟，將重複繁瑣部分自動化以降錯與控風險。
• A詳: CD 與環境高度耦合，若短期無法打通，文章建議半自動策略：CI 自動打包與推送到套件庫/Registry，部署端以簡單、可重複的命令從唯一來源安裝/拉取。保留的人工步驟應簡短且低風險（如按一下、執行一條命令），避免複雜手工操作。此法能快速落地與降錯，並為日後全自動化鋪路。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q9, A-Q13, A-Q14

A-Q24: 什麼是「X as Code」？為何重要？

• A簡: 將流程/設定以程式碼表達與版控，保證可重複、可審計與可協作，例如 pipeline、部署、文件皆可程式化。
• A詳: 「X as Code」理念將本可手動的工作（如 pipeline 定義、基礎設施、文件、網站）用程式碼描述，納入版控與審查流程。文章以「Blogging as code」自例，說明此法能強化可追溯、變更管理與自動化。對 CI/CD 而言，.gitlab-ci.yml、Dockerfile、部署腳本、版本資訊等皆屬此範疇，使團隊共享事實來源，降低「人記憶」的不確定性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q5, B-Q8

Q&A 類別 B: 技術原理類

B-Q1: GitLab CI Pipeline 如何從推送運作到產出成品？

• A簡: 推送觸發 Pipeline，Runner 依 .gitlab-ci.yml 執行建置、測試、打包，產出 artifacts 與狀態回饋。
• A詳: 技術原理說明：Git push/MR 觸發 GitLab 的 Pipeline，排程器依 .gitlab-ci.yml 定義建立 stages 與 jobs。Runner 拉取該 commit 的快照，在乾淨環境執行指令（如 build/test），產出 artifacts 與測試報告。關鍵步驟或流程：觸發→排程→Runner 取碼→執行→上傳產物→標記狀態→通知。核心組件介紹：GitLab（控制平面）、Runner（執行器）、Artifact 儲存、通知系統。整體形成可觀測、可追溯的自動化迴路。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q21, C-Q1

B-Q2: Git Flow 的執行流程為何？

• A簡: 以 develop 為開發主線，feature 開發後併回；出版本建 release 分支，最終併入 master 與 develop；修補用 hotfix。
• A詳: 技術原理說明：Git Flow 透過分支角色分離責任。關鍵步驟或流程：1) feature/{name} 從 develop 分出，完成併回 develop；2) 發版時從 develop 建 release/{version}，只修穩定性，準備完成後併回 master 與 develop，並標籤；3) 緊急修補從 master 建 hotfix/{issue}，完成後併回 master 與 develop。核心組件介紹：長存分支（master/develop）、短期分支（feature/release/hotfix）、標籤（tags）。此流程讓並行開發、發版與修補互不干擾。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, A-Q10, C-Q2

B-Q3: Artifacts 如何被儲存與取用？

• A簡: 由 Runner 上傳至集中儲存，標記版本與來源；CD 或他專案透過 URL/套件庫拉取使用。
• A詳: 技術原理說明：CI 任務完成後，Runner 依設定將 artifacts（壓縮包、二進位檔、報告）上傳至 GitLab Artifact 儲存或套件管理。關鍵步驟或流程：產出→命名/標記（含 commit SHA、版本）→上傳→保留策略→權限控管→取用。核心組件介紹：Artifact 儲存、Package Registry、存取權限（Token/Scopes）。集中管理避免重建，支撐跨環境部署與回滾。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q1, C-Q4

B-Q4: 套件管理機制如何運作？

• A簡: 利用索引與中繼資料管理版本與相依性，客戶端解析樹狀依賴並下載校驗，提供一致安裝來源。
• A詳: 技術原理說明：套件庫維護索引（名稱、版本、相依），發佈時上傳包與中繼資料，安裝時客戶端解析依賴圖、選擇版本、下載與校驗。關鍵步驟或流程：發佈→索引更新→安裝解析→下載→驗證→快取。核心組件介紹：Registry（npm/nuget/apt）、客戶端（npm/nuget/apt-get）、權限與鏡像。此機制使 CD 可依版本策略與渠道自動選用正確產物。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, C-Q4, D-Q7

B-Q5: 為何 Docker Registry 等同一種「套件管理」？

• A簡: 映像以標籤版本化、集中儲存與權限控制；環境以拉取映像部署，流程與套件庫相同。
• A詳: 技術原理說明：容器映像（Image）含層（layers）與中繼資料，以標籤管理版本，推送至 Registry（如 GitLab/Hub）。環境部署時以 pull 取得對應標籤，具備來源一致、可追溯與回滾快速的特性。關鍵步驟或流程：建構→標籤（含 SemVer/渠道）→推送→拉取→部署。核心組件介紹：Dockerfile、Registry、Credential、標籤策略。這讓網站/服務的 CD 與傳統套件同樣標準化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, C-Q5, C-Q9

B-Q6: SemVer 在 develop/master 流程中如何使用？

• A簡: develop 產生預發佈版（-beta/-rc），master 產生正式版（x.y.z）；標籤帶出變更幅度與穩定度。
• A詳: 技術原理說明：分支對應渠道，develop 的 Pipeline 產生 pre-release 標籤（如 1.3.0-beta.5），master 標正式（1.3.0）。關鍵步驟或流程：決定版本位數→在建置時注入版本（環境變數）→標記 Git Tag→發佈到套件庫/Registry。核心組件介紹：版本計算腳本、Tag、Package/Registry。此策略讓消費者與部署端能自動（或手動）選擇合適穩定度與回滾目標。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, C-Q3, B-Q10

B-Q7: 事件觸發與排程觸發有何差異？VSS 為何不適合 CI？

• A簡: 事件觸發即時回饋，排程延遲。VSS 缺乏事件與服務能力，只能排程，整合速度與維護性差。
• A詳: 技術原理說明：事件觸發（webhook/push）能於變更發生即觸發 Pipeline，縮短回饋迴路；排程觸發（cron）則固定時間啟動，存在延遲。關鍵步驟或流程：事件→CI 平台→Runner；或排程→取碼→建置。核心組件介紹：Webhook、Runner、排程器。文章提到 VSS 僅為檔案型資料庫、非服務，缺少事件能力，導致只能 Daily Build，維護負擔與反饋速度皆不佳。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, B-Q1, D-Q10

B-Q8: 最小可行 CI 架構如何設計？

• A簡: 以版控＋CI＋Artifacts 為核心，只做成功建置、單元測試與成品管理，確保回饋與可部署性。
• A詳: 技術原理說明：以最小集合建立可觀測迴路：變更→建置→測試→產物。關鍵步驟或流程：1) 觸發 Pipeline；2) build 成功；3) 單元測試通過；4) 上傳 artifacts（含版本/commit）；5) 通知。核心組件介紹：Git、CI 平台（GitLab CI）、Runner、Artifact 儲存。此設計成本小、成效快，是導入 CI/CD 的關鍵第一步，之後再加上掃描、整合測試、部署等階段。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q17, C-Q1, A-Q21

B-Q9: CI 的通知架構如何運作？

• A簡: 平台依使用者訂閱與事件，透過 Web、Email、App、Webhook 送出狀態與變更通知。
• A詳: 技術原理說明：當 Pipeline 狀態變更（通過/失敗/被阻擋）或有新產物時，通知模組根據接收者偏好（關注者、MR 參與者）推播。關鍵步驟或流程：事件→通知排程→通道（Email/App/Webhook）→接收端。核心組件介紹：Notification Service、使用者設定、群組與項目訂閱。這讓回饋可達與可自訂，縮短問題發現至修復的時間。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q22, C-Q10, B-Q1

B-Q10: 分支與發行通道如何對應設計？

• A簡: 將 develop 對應 Beta、master 對應 RC/RTM，透過規則決定版本與發佈目的地與核准需求。
• A詳: 技術原理說明：以分支名作為部署政策的決策因子（rules/only），決定版本型態（pre/正式）、發佈庫（測試/正式）與核准流程。關鍵步驟或流程：識別分支→計算版本→發佈到對應庫/Registry→標籤與通知。核心組件介紹：CI 規則（rules）、環境（environments）、標籤策略。此設計讓「一個主幹多通道」落地，降低手動錯配風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q6, C-Q6

B-Q11: CI/CD 如何建立安全供應鏈？

• A簡: 建置、簽署、發佈集中於平台，產物帶來源與版本證據，部署僅允許可信來源，形成可稽核鏈。
• A詳: 技術原理說明：將建置權限與環境隔離，CI 以乾淨環境建產物，附帶 commit/版本中繼資料，推送至受控的產物庫/Registry。關鍵步驟或流程：源碼→建置→產物簽章/標籤→發佈→部署拉取→審計。核心組件介紹：CI 平台、Artifact/Registry、憑證與存取控制。如此避免開發者本機任意 build 上線，亦便於事後追查與回滾。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, D-Q6, B-Q14

B-Q12: 如何評估並整併工具組？

• A簡: 清點功能重疊、學習與維運成本，選擇能滿足未來數年需求的一體化平台，制定遷移步驟。
• A詳: 技術原理說明：以能力矩陣盤點版本控制、議題、CI/CD、套件庫等功能，評估重疊度與整合成本。關鍵步驟或流程：盤點→比較→選型（如 GitLab）→試點→遷移→下線舊系統。核心組件介紹：目標平台（GitLab）、身分與授權、資料遷移工具。文章主張「少即是多」，先善用既有工具、再考慮替換，降低阻力與學習曲線。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q7, D-Q4

B-Q13: 單元測試如何同時作為規格與範例？

• A簡: 以測試描述 API 行為，範例即規格；遇到缺陷先寫重現測試，再修復避免回歸。
• A詳: 技術原理說明：測試以可執行規格（executable spec）記錄行為契約，命名與斷言即說明文件。關鍵步驟或流程：定義行為→撰寫測試→實作/修正→在 CI 驗證。核心組件介紹：測試框架、斷言庫、CI 測試報告。文章建議：新功能用 TDD、缺陷以測試重現、函式庫用測試提供用法範例。如此測試兼具文件與防護網的價值。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q8, D-Q2

B-Q14: 如何建立「來源可追溯」的產物鏈？

• A簡: 以 commit SHA、版本與分支標記產物，從部署物逆向可還原到源碼、測試與審核紀錄。
• A詳: 技術原理說明：在建置時將 Git 資訊（SHA、branch、tag）寫入版本檔或中繼資料，產物命名與發佈也含版本與渠道。關鍵步驟或流程：注入→命名→發佈→記錄→查詢。核心組件介紹：版本注入腳本、Artifact 庫、查詢介面。這使得環境中的任一檔案都能被追溯至其源碼與審核紀錄，支援稽核與事故處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, B-Q11, D-Q3

B-Q15: 容器如何統一執行環境並降低耦合？

• A簡: 封裝系統依賴與應用，確保跨機器一致；以映像層快取與不可變部署，減少「環境不同」問題。
• A詳: 技術原理說明：容器在 OS 層以隔離機制運行，使用映像層（layers）堆疊重用依賴。關鍵步驟或流程：撰寫 Dockerfile→建立映像→推送→環境拉取→運行。核心組件介紹：容器引擎、Registry、映像標籤。容器化使部署可預測、回滾迅速，並與 CI/CD 無縫對接，是文章推薦的 CD 簡化解法。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, C-Q5, C-Q9

B-Q16: Daily Build 與事件驅動 CI 的差異是什麼？

• A簡: Daily Build 為排程、回饋慢且集中；事件驅動即時、粒度細。前者適用舊工具過渡。
• A詳: 技術原理說明：Daily Build 依排程統一建置，優點是簡單易控；缺點是延遲高、問題定位較晚。事件驅動 CI 以每次提交觸發，優點是快速回饋與小批量整合。關鍵步驟或流程：排程 vs webhook。核心組件介紹：排程器、VCS 事件、CI 平台。文章以 VSS 與虛擬機實作 Daily Build 作為過去過渡策略，現代推薦事件驅動。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, B-Q7, D-Q10

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何以 GitLab CI 實作最小 Pipeline（建置、測試、成品）？

• A簡: 定義 .gitlab-ci.yml 含 build/test/artifacts，Runner 執行後上傳產物並回饋狀態，完成最小 CI。
• A詳: 具體實作步驟：1) 在專案根目錄新增 .gitlab-ci.yml；2) 定義 stages: [build, test]；3) 在 build job 編譯並輸出到 dist/；4) 在 test job 執行單元測試；5) 設定 artifacts: paths 指向 dist/ 與報告。關鍵程式碼片段或設定： stages: [build, test] build: stage: build script: [npm ci, npm run build] artifacts: { paths: [dist/] } test: stage: test script: [npm test – –ci –reporters=junit] dependencies: [build]
• 注意事項與最佳實踐：確保可重複建置（鎖定版本）、在乾淨環境執行、命名與保留策略妥善。將 commit SHA 注入版本資訊以利追溯。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, A-Q8, A-Q12

C-Q2: 如何設定基本 Git Flow（僅 master 與 develop）與分支保護？

• A簡: 建立 develop，保護 master/develop，限定 MR 合併，漸進導入 feature/release/hotfix。
• A詳: 具體實作步驟：1) 從主分支建立 develop；2) 在平台開啟分支保護，禁止直接 push 至 master/develop；3) 設 MR 規則（需審核/通過 CI 才能併入）；4) 在開發時從 develop 建短期分支，完成後提 MR 回 develop。關鍵設定：分支保護、必需通過 Pipeline、最少審核者數。注意事項與最佳實踐：制定命名規範（feature/*）、小步提交與頻繁合併；待團隊成熟再引入 release/hotfix 流程。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q11, B-Q2, B-Q10

C-Q3: 如何標記版本並套用 SemVer 與預發佈標記？

• A簡: 以 x.y.z 與 -beta/-rc 命名版本，於建置時注入版本與 Git Tag，對應分支產生不同渠道。
• A詳: 具體實作步驟：1) 決定版本策略（例：develop 產出 1.4.0-beta.{CI_PIPELINE_IID}，master 產出 1.4.0）；2) 建置時注入 VERSION 環境變數；3) 在發版 job 創建 Tag。關鍵程式碼片段或設定： script:
  • export VERSION=$(node scripts/version.js) # 依分支產生
  • echo $VERSION > version.txt
  • git tag -a “v$VERSION” -m “Release $VERSION”
  • git push –tags
• 注意事項與最佳實踐：版本不可回溯修改；預發佈與正式分庫管理；在產物名稱與映像標籤帶版本與 SHA。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, A-Q15, B-Q14

C-Q4: 如何將成品發佈到套件管理（以 GitLab Package Registry/通用倉庫為例）？

• A簡: 在 CI 中打包並以 API/CLI 上傳至 Registry，之後以唯一 URL 與版本拉取部署。
• A詳: 具體實作步驟：1) 設定個人或專案存取 Token；2) 建置產物（如 .tgz/.zip）；3) 使用 curl 或包管理 CLI 上傳。關鍵程式碼片段或設定（Generic Packages）： script:
  • tar -czf app-$VERSION.tgz dist/
  • curl –header “JOB-TOKEN:$CI_JOB_TOKEN” –upload-file app-$VERSION.tgz “$CI_API_V4_URL/projects/$CI_PROJECT_ID/packages/generic/app/$VERSION/app-$VERSION.tgz”
• 注意事項與最佳實踐：規範命名與路徑；權限最小化；在 README/文件中提供安裝指令，確保部署端能穩定取用。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q4, A-Q13

C-Q5: 如何容器化網站並推送至 Registry？

• A簡: 撰寫 Dockerfile、建映像、標籤版本與渠道、登入 Registry 並推送，供環境拉取部署。
• A詳: 具體實作步驟：1) 撰寫 Dockerfile；2) CI 建置二進位後 docker build；3) 以版本與 SHA 標籤；4) 登入 Registry 並 docker push。關鍵程式碼片段或設定： Dockerfile: FROM node:18-alpine COPY dist/ /app CMD [“node”, “/app/server.js”] CI:
  • docker build -t $CI_REGISTRY_IMAGE:$VERSION .
  • docker push $CI_REGISTRY_IMAGE:$VERSION
• 注意事項與最佳實踐：使用多階段建置縮小映像；標籤同時包含語意版與 SHA；Registry 權限控管與過期策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, A-Q14, C-Q9

C-Q6: 如何為 develop/master 設定不同 Pipeline 規則與部署策略？

• A簡: 以 rules/only 判斷分支，產生預發佈或正式版，發佈至對應 Registry/套件庫與環境。
• A詳: 具體實作步驟：1) 在 .gitlab-ci.yml 使用 rules: if: ‘$CI_COMMIT_BRANCH == “develop”’ 決定流程；2) develop 產出 -beta 版本並發佈到測試庫；3) master 產正式版到正式庫。關鍵程式碼片段或設定： rules:
  • if: ‘$CI_COMMIT_BRANCH == “develop”’ variables: { CHANNEL: “beta” }
  • if: ‘$CI_COMMIT_BRANCH == “master”’ variables: { CHANNEL: “release” }
• 注意事項與最佳實踐：避免手動覆寫渠道；必要時加入人工核准；產生對應通知與發佈記錄。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q6, C-Q3

C-Q7: 如何從多工具（GitLab+TFS+Jenkins+Redmine）整併到 GitLab？

• A簡: 盤點功能與資料、選擇 GitLab 為核心、試點遷移、分批切換並下線舊系統，降低風險。
• A詳: 具體實作步驟：1) 盤點專案、流程與重疊功能；2) 定義目標狀態（GitLab: 版控+議題+CI+Package）；3) 選一專案試點遷移（Repo、Issues、Pipelines）；4) 撰寫遷移指南與訓練；5) 滾動遷移並關閉舊節點。關鍵設定：分支保護、Runner 設定、Package Registry 啟用。注意事項與最佳實踐：保留可回退計畫；用度量（Build 成功率、Lead time）驗證成效；避免同時大爆改流程與工具。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, A-Q18, D-Q4

C-Q8: 既有專案如何開始寫單元測試並導入 CI？

• A簡: 新功能先行 TDD，對缺陷寫重現測試，逐步擴大覆蓋；CI 強制測試通過才合併。
• A詳: 具體實作步驟：1) 選定測試框架；2) 對新功能以 TDD 撰寫測試；3) 每個回報缺陷先寫重現測試再修；4) 將測試融入 CI 流程，設定合併門檻；5) 持續重構與抽象以提升可測性。關鍵程式碼片段或設定：在 CI 的 test job 中輸出 JUnit/HTML 報告，作為 MR 的品質信號。注意事項與最佳實踐：避免一次性補齊；重點覆蓋風險區域；建立命名與資料夾結構規範，讓測試也成為文件。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, B-Q13, D-Q2

C-Q9: 如何實作「半自動 CD」？

• A簡: 自動打包與發佈到套件庫/Registry，部署端以標準命令拉取安裝；保留必要的人工核准。
• A詳: 具體實作步驟：1) CI 產生 artifacts 與版本；2) 發佈至套件庫/Registry（測試/正式分離）；3) 部署手冊提供單一命令拉取安裝（如 apt-get install app=1.2.3 或 docker pull/tag/run）；4) 設置人工核准與變更紀錄。關鍵程式碼片段或設定：在 README/Runbook 內提供命令；CI 輸出發佈頁面與版本清單。注意事項與最佳實踐：確保部署步驟簡單、一致、可重複；避免複雜手動配置；逐步自動化剩餘環節。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q23, B-Q5, C-Q5

C-Q10: 如何建立 Pipeline 看板與通知機制？

• A簡: 啟用專案關注、Email/App 通知，配置狀態徽章與總覽頁，讓團隊即時掌握健康度。
• A詳: 具體實作步驟：1) 在 GitLab 進入「通知」設定選擇頻率；2) 手機安裝 GitLab App 登入接收推播；3) 在 README 加入 Pipeline、Coverage 徽章；4) 建立群組層級總覽頁收攏多專案燈號。關鍵設定：Protected Branch 與必須通過 Pipeline 的合併規則。注意事項與最佳實踐：避免通知疲勞（合理聚合）；將看板置於團隊共用螢幕；遇紅燈建立當班處理機制。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q22, B-Q9, C-Q1

Q&A 類別 D: 問題解決類（10題）

D-Q1: 遇到「Build 失敗」怎麼辦？

• A簡: 先看 Pipeline 日誌定位錯誤，於本機重現與修復；提交後驗證。建立預防的可重複建置與快取。
• A詳: 問題症狀描述：編譯或打包階段失敗，Pipeline 轉紅。可能原因分析：缺少依賴、版本變動、環境差異、腳本錯誤。解決步驟：1) 檢視失敗 job 日誌；2) 在乾淨本機/容器重現；3) 修正依賴版本或腳本；4) 補測與提交；5) 觀察 Pipeline 回綠。預防措施：鎖定依賴（lockfile）、使用容器化建置、建立快取策略與 pre-commit 檢查，確保建置可重複與穩定。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q1, B-Q1, D-Q8

D-Q2: 單元測試不穩定或不足怎麼辦？

• A簡: 先處理 flaky 測試（時間/外部依賴），逐步擴充關鍵路徑覆蓋；建立 TDD 與缺陷先寫測試文化。
• A詳: 問題症狀描述：測試偶發失敗或覆蓋率低。可能原因分析：非決定性（時間、隨機、網路）、耦合過高、測試設計不良。解決步驟：1) 隔離外部依賴（mock/stub）；2) 移除睡眠等待，改可觀測條件；3) 聚焦關鍵業務路徑與風險模組擴充測試；4) 在 CI 設定必須通過門檻。預防措施：TDD、小步提交、重構提升可測性、統一測試約定與報告格式。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q8, B-Q13

D-Q3: 發現產物無法追溯到對應 commit，怎麼修？

• A簡: 在建置注入版本與 SHA，規範命名與標籤；將所有部署來源收斂至產物庫/Registry。
• A詳: 問題症狀描述：不清楚某環境部署自哪次源碼，回溯困難。可能原因分析：手動 build/上傳、命名混亂、缺乏標籤與紀錄。解決步驟：1) 修改建置腳本注入 commit SHA/版本；2) 規範 artifacts/映像命名；3) 在 CD 只允許從受控來源部署；4) 對現有環境建檔標記現況。預防措施：建立「來源可追溯」標準（BOM/Manifest）、強制使用 CI 產物、鎖定部署管道。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, A-Q12, D-Q6

D-Q4: 工具太多彼此重疊，導致流程混亂，怎麼整頓？

• A簡: 盤點功能與成本，選定核心平台試點整併，分批遷移並下線舊系統，建立治理原則。
• A詳: 問題症狀描述：多人用不同系統管理同一流程，資料分散、學習成本高。可能原因分析：歷史遺留、各自偏好、缺乏治理。解決步驟：1) 盤點工具與流程映射；2) 制定選型標準（能力/成本/未來性）；3) 選一體化平台（如 GitLab）試點；4) 擬訂遷移與下線計畫；5) 訓練與回饋。預防措施：建立工具引入評估流程、定期治理審查與指標觀測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, C-Q7, A-Q18

D-Q5: 團隊對新流程反彈，如何推動落地？

• A簡: 從最小可行流程起步，快速顯效；溝通品質與資安價值，提供培訓與支持，逐步擴展。
• A詳: 問題症狀描述：抱怨流程繁瑣、效率變慢。可能原因分析：看不見價值、學習成本、習慣改變。解決步驟：1) 以最小 CI（build/test/artifacts）起步；2) 用數據展示紅燈早期發現與回歸下降；3) 安排培訓與 Pair；4) 邀請倡議者擔任內部教練；5) 漸進式擴展。預防措施：明確成功指標、設定合理門檻、將流程內化為開發日常（模板、腳本化）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, B-Q8, C-Q8

D-Q6: 手動部署造成資安風險，如何補強？

• A簡: 禁止本機上線，部署只允許 CI 產物；權限最小化與審計，建立變更核准與回滾機制。
• A詳: 問題症狀描述：開發者可直接上傳檔案到正式環境。可能原因分析：缺乏流程與管控。解決步驟：1) 建立 CI 產物庫/Registry；2) 正式環境僅允許從受控來源部署；3) 移除直連權限，導入審計；4) 建立核准與版本記錄；5) 以容器或套件統一部署入口。預防措施：政策與技術雙軌落地、定期稽核、演練回滾與事故流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, B-Q11, D-Q3

D-Q7: 套件相依衝突（Dependency Hell）怎麼辦？

• A簡: 鎖定版本與建立內部鏡像，審查重大升級；在 CI 驗證相依解析，避免漂移。
• A詳: 問題症狀描述：安裝失敗或運行期崩潰。可能原因分析：相依版本範圍過寬、轉換依賴變更、外部倉庫不穩。解決步驟：1) 使用鎖定檔（package-lock、yarn.lock、nuget.lock）；2) 釘選關鍵相依版本；3) 設立內部鏡像/代理；4) 在 CI 中做「乾淨安裝」與測試；5) 對重大版本升級採藍綠/金絲雀。預防措施：SemVer 紀律、定期安全更新、依賴白名單。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, C-Q4, B-Q6

D-Q8: Pipeline 執行太慢，如何優化？

• A簡: 以快取與並行化、拆分階段、精簡映像、增量建置與只跑必要測試，縮短總時長。
• A詳: 問題症狀描述：等待時間長、回饋慢。可能原因分析：單一巨型 Job、映像過大、重複安裝依賴。解決步驟：1) 啟用依賴快取與 artifacts 重用；2) 拆分為可並行的 Jobs；3) 使用預建輕量映像；4) 以測試選擇器只跑受影響套件；5) 引入 Runner 池與自動擴展。預防措施：持續監測 Pipeline 指標、定期重構 CI 腳本、將重型步驟容器化與分層。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, B-Q1, D-Q1

D-Q9: 分支混亂、衝突頻仍，如何收斂？

• A簡: 明確採用 Git Flow，保護主幹與開發線，強制 MR 與 CI 通過，小步合併降低漂移。
• A詳: 問題症狀描述：分支命名隨意、長期分叉、合併衝突多。可能原因分析：缺乏分支策略與合併門檻。解決步驟：1) 宣告 Git Flow 最小版（master/develop）；2) 設定分支保護與 MR 必須通過 CI；3) 制定命名與壽命規則（短期分支）；4) 推動小批量合併與頻繁同步主幹。預防措施：流程文件化與看板可視、定期健康檢查（未合併分支監控）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q2, B-Q2, A-Q11

D-Q10: 從 VSS/TFS 過渡到 Git 與現代 CI 有哪些重點？

• A簡: 先資料遷移與歷史保留，採事件驅動 Pipeline；短期可用排程過渡，最終統一到 Git 與 GitLab CI。
• A詳: 問題症狀描述：舊系統缺事件觸發、流程割裂。可能原因分析：工具限制與歷史包袱。解決步驟：1) 規劃版本史遷移（保留作者/時間）；2) 在 Git 建立分支策略；3) 以 GitLab CI 取代排程式建置；4) 過渡期可保留 Daily Build 以降低風險；5) 訓練團隊 Git/CI 流。預防措施：試點與逐步切換、雙寫緩衝期、明確下線時間表與回退策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q7, B-Q16

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 CI（持續整合）？
  • A-Q2: 什麼是 CD（持續交付/部署）？
  • A-Q3: 什麼是 DevOps？
  • A-Q4: 為什麼不要「工具先行」？
  • A-Q5: 團隊為何需要 CI/CD？
  • A-Q6: 版本控制的核心價值是什麼？
  • A-Q8: CI 與 CD 有何差異？
  • A-Q10: Git Flow 中哪些分支是長期存在的？
  • A-Q11: 為何建議先從 master/develop 開始？
  • A-Q12: 什麼是建置成品（Artifacts）管理？
  • A-Q15: 什麼是 SemVer？為何建議採用？
  • A-Q16: 什麼是「Daily Build」？
  • A-Q21: 什麼是 Pipeline？
  • A-Q22: CI 執行結果的回饋方式有哪些？
  • C-Q1: 如何以 GitLab CI 實作最小 Pipeline（建置、測試、成品）？
• 中級者：建議學習哪 20 題
  • A-Q7: 何謂發行管理（Release Management）？
  • A-Q13: 套件管理在 CD 中扮演什麼角色？
  • A-Q14: 為何容器化能簡化部署？
  • A-Q17: 為何導入 CI/CD 要循序漸進？
  • A-Q18: 為何應整併功能重疊的工具？
  • A-Q19: 單元測試在 CI 的價值是什麼？
  • A-Q20: CI/CD 如何強化資安？
  • B-Q1: GitLab CI Pipeline 如何從推送運作到產出成品？
  • B-Q2: Git Flow 的執行流程為何？
  • B-Q3: Artifacts 如何被儲存與取用？
  • B-Q4: 套件管理機制如何運作？
  • B-Q5: 為何 Docker Registry 等同一種「套件管理」？
  • B-Q6: SemVer 在 develop/master 流程中如何使用？
  • B-Q8: 最小可行 CI 架構如何設計？
  • B-Q10: 分支與發行通道如何對應設計？
  • B-Q11: CI/CD 如何建立安全供應鏈？
  • C-Q2: 如何設定基本 Git Flow（僅 master 與 develop）與分支保護？
  • C-Q3: 如何標記版本並套用 SemVer 與預發佈標記？
  • C-Q4: 如何將成品發佈到套件管理（以 GitLab Package Registry/通用倉庫為例）？
  • D-Q5: 團隊對新流程反彈，如何推動落地？
• 高級者：建議關注哪 15 題
  • B-Q12: 如何評估並整併工具組？
  • B-Q14: 如何建立「來源可追溯」的產物鏈？
  • B-Q15: 容器如何統一執行環境並降低耦合？
  • B-Q16: Daily Build 與事件驅動 CI 的差異是什麼？
  • C-Q5: 如何容器化網站並推送至 Registry？
  • C-Q6: 如何為 develop/master 設定不同 Pipeline 規則與部署策略？
  • C-Q7: 如何從多工具（GitLab+TFS+Jenkins+Redmine）整併到 GitLab？
  • C-Q8: 既有專案如何開始寫單元測試並導入 CI？
  • C-Q9: 如何實作「半自動 CD」？
  • D-Q3: 發現產物無法追溯到對應 commit，怎麼修？
  • D-Q4: 工具太多彼此重疊，導致流程混亂，怎麼整頓？
  • D-Q6: 手動部署造成資安風險，如何補強？
  • D-Q7: 套件相依衝突（Dependency Hell）怎麼辦？
  • D-Q8: Pipeline 執行太慢，如何優化？
  • D-Q10: 從 VSS/TFS 過渡到 Git 與現代 CI 有哪些重點？