CI/CD 是什麼？

CI/CD 是現代軟體開發中一個至關重要的流程，分別代表持續整合（Continuous Integration, CI）和持續交付/持續部署（Continuous Delivery/Deployment, CD）。CI 目的是幫助開發團隊頻繁迭代，將程式碼整合到主分支中，並通過自動化測試來確保程式碼品質，盡可能早發現問題並修復潛在問題。CD 則負責自動化部署，將測試通過的程式碼快速部署到生產環境中。

那在 CI/CD 之前呢？是怎麼開發的？

CI/CD 的發展

最早在 1990 年代持續整合（Continuous Integration, CI）和持續交付（Continuous Delivery/Deployment, CD）的概念逐漸被提出，但這些直到 2010 年代初才逐漸被廣泛應用。

在 CI/CD 成為主流之前，軟體開發通常依賴於瀑布式開發方法（Waterfall Development）瀑布式開發過程中，所有的需求收集、設計、實施、測試和部署是依次進行的。這種模式往往會導致發佈週期長，當最終整合時，錯誤往往難以及時發現且修復成本高，而且過去的流程多為手動進行，需要在本機執行、測試並手動部署程式碼，這種方式不僅效率低，且容易因環境不一致導致生產環境出現意外錯誤。

簡言之，過去的問題有：發佈週期長、手動效率差、環境不一致、除錯成本高

CI/CD 的發展史

CI 伺服器軟體 => CI 即服務 => 與 Git 託管平台整合

1. 第一階段：CI 伺服器軟體
   2001 年 ThoughtWorks 創建了第一個廣泛使用的 CI 工具 CruiseControl，操作繁瑣且資源浪費嚴重。2005 年，Hudson 成立（後來的 Jenkins），一個開源的、靈活的 CI 伺服器，並廣泛應用於本地部署環境中。

2. 第二階段：CI 即服務 (CI as a Service)：
   2010 年代初，隨著雲計算技術的發展，CI 工具開始轉向雲端服務模式。例如：Travis CI 和 CircleCI，它們將 CI/CD 與儲存庫（GitHub）整合，並提供基於雲端的自動化建立和測試服務，大幅簡化了 CI/CD 的部署和管理，透過這種方式不用再維護本地伺服器。

3. 第三階段：與 Git 託管平台整合：
   從 2015 年起，GitLab 開始將 CI/CD 功能直接整合到其 Git 託管服務中，實現了從程式碼提交到測試與部署的一條龍服務。2018 年，GitHub 也推出了 GitHub Actions，進一步推動了 CI/CD 與版本控制平台的緊密結合，不再需要單獨使用 CI 工具，所有操作都可以直接在版本管理平台上完成。

CI/CD 具體內容

CI 包含哪些事？

持續整合 (CI) 是一個自動化的過程，從開發者 commit 和 push 後，會觸發一系列的測試與檢查。以下是 CI 流程中包含的步驟：

1. 提交與自動化測試

當程式碼推送到遠端分支時，CI 系統會自動啟動測試流程，包括單元測試和整合測試，檢查新程式碼是否引入錯誤。

2. 程式碼檢測

CI 流程中還會運行靜態程式碼分析和程式碼格式化檢查，確保符合團隊的風格指南和語言規範。

3. 構建與集成

在基礎測試和程式碼 style 通過後，CI 系統會自動建立應用程式並生成可執行文件或容器映像(Image 或Container，依照不同測試環境運行方式)，看新提交程式是否會導致其他問題。

4. 自動回饋

若測試或構建失敗，CI 系統會及時發送通知給相關開發人員，讓他們能夠迅速修復問題。

CD 包含哪些事？

持續交付/部署 (CD) 負責將通過 CI 的程式碼部署到測試或生產環境。目標就是自動化這一過程，讓程式開發能夠更頻繁的迭代。

1. 自動化部署流水線：

通過測試後，CD 會自動觸發部署流程，將程式碼部署到測試環境或生產環境。這一過程完全自動化，無需手動操作。

簡言之就是將測試通過的內容合併到正在運行的分支(main/master/production，看團隊的定義)

2. 環境配置與部署驗證：

部署過程中，系統會根據不同環境配置參數，確保應用能夠在不同的環境中正確運行。部署完成後，會進行驗證測試，檢查應用是否正常工作。

這部分簡言之就是專案中的 .env，例如測試站會設定不同連接的 db 或是對應不同 port 等等。

3. 自動化回滾(rollback)機制：

如果部署過程中發現異常或生產環境中出現問題，CD 系統可以自動回滾到上一個穩定版本，保障系統的連續性和穩定性。

那具體開發和部署時，分支會怎麼設計呢？
這就牽扯到 branching models 了，有 git flow、gitlab flow、github flow，到底實際上什麼才是最好的，只能讓團隊自己討論適合的方式了

Data Pipeline CI / CD 的差異

主要核心差異在於處理的對象不同。普通 CI/CD 主要針對應用程式開發，重點在於程式碼的整合和應用部署。而 Data Pipeline CI/CD 則專注於數據的處理和數據流的管理，涉及到數據品質測試和控制、上下游依賴管理和資料庫遷移。

1. 數據質量控制

Data Pipeline 的 CI/CD 需要針對數據質量進行檢測，這與應用程式的程式碼測試不同。數據的完整性和正確性是重點，確保數據在流轉過程中不會出現錯誤

2. 依賴與調度管理

Data Pipeline 的執行大量依賴於數據的更新和外部來源的狀況，因此 CI/CD 流程需要考慮數據的調度和依賴管理，這比普通的應用程式部署要複雜得多

3. 資料庫遷移和變更

在數據處理管道中，數據庫的結構變更是另一個挑戰。與應用程式程式碼的變更不同，數據庫遷移需要小心處理，否則可能導致數據丟失或損壞。

4. 更多的檢查和通知

因為數據流會因爲來源而常常產生意料外的錯誤，所以在不同的資料節點，需要設定更多資料檢查的工具，以確保後續提供的資料是有品質的，不去設定也可以順利運行，但可能等到業務或是成效分析後，才會知道資料源頭已經被污染，就是大家常說的 GIGO (Garbage in, garbage out），這時候要在清理資料就會變得非常麻煩了～