CI/CD 原理的解題技巧：持續集成&持續交付/部署

CI/CD 其實分成三個階段，其在實際應用上有時並無明確分別而是一個概念

意指能夠將團隊寫好的程式碼在遞交到正式環境之前就能檢測是否採用統一的標準，以避免不同環境不同人撰寫的程式碼在整合時出現錯誤。

而 Continuous Delivery 持續交付跟 Continuous Deployment 持續部署，因概念相近又更常被包含在同一個概念內統稱 CD。

1. Continuous Integration（CI）：持續整合
2. Continuous Delivery（CD）：持續交付
3. Continuous Deployment（CD）：持續部署

圖片來源: 理解 CI 與 CD 間的差異

一、Continuous Integration（CI）：持續整合

CI 持續整合讓我們可以確定新代碼和原有代碼能否正確地集成在一起

提交間隔越久的開發者，處理程式碼的衝突，就越困難。而且還可能造成團隊的成員重複解決相同程式區塊的衝突。整合的時間越晚，整合的難度與失敗的機率就越高。

持續整合的目的，利用頻繁地提交新功能的變更，觸發自動化建置和測試，確保最新版本的軟體是可運行的。

• 版本控制: 持續整合最重要的一步，可以說，沒有版控，就沒有 CI/CD
• 建置: 確保提交的程式碼是否可以執行的
  • 保證 push 上去後的程式碼不會導致整個專案無法編譯成功
  • 例如有可能環境變數、版本套件的原因導致這些問題
  • 自動化的流程幫我們自動編譯好，看新 push 上去的程式碼有沒有出現錯誤
• 自動化測試 確保功能正常與軟體品質
  • 保證新 push 上去的程式碼，不僅可以被成功建置也保證專案的功能沒有出現漏洞
• 程式碼分析: 檢查 code style 或程式的穩健度

圖片來源: DevOps、CI、CD 都是什麼鬼？

二、Continuous Delivery（CD）：持續交付

CD 持續交付的目標是擁有一個可隨時部署到生產環境的代碼庫

在持續交付中，每個階段（從代碼更改的合併，到生產就緒型構建版本的交付）都涉及測試自動化和代碼發佈自動化。在流程結束時，運維團隊可以快速、輕鬆地將應用部署到生產環境中或發佈給最終使用的用戶。

持續交付並不是指軟件每一個改動都要儘快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。

圖片來源: DevOps、CI、CD 都是什麼鬼？

三、Continuous Deployment（CD）：持續部署

CD 持續部署意味着所有的變更都會被自動部署到生產環境中

對於一個成熟的 CI/CD 管道（Pipeline）來說，最後的階段是持續部署。作爲持續交付——自動將生產就緒型構建版本發佈到代碼存儲庫——的延伸，持續部署可以自動將應用發佈到生產環境。

持續交付意味着所有的變更都可以被部署到生產環境中，但是出於業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。持續部署意味着所有的變更都會被自動部署到生產環境中。

圖片來源: DevOps、CI、CD 都是什麼鬼？

四、CI/CD 的工具

目前主要的兩個代碼託管庫 GitHub 和 GitLab 都已有支援 CI/CD 的服務且越趨完整，若是有特殊需求可考慮老牌的 Jenkins CI/CD 和 Travis CI。

簡單的實際操作範例可見 CI/CD: GitHub Actions 自動部署到 GitHub Page 一文。

圖片來源: 什麼是 CI / CD ?

如果我們深入研究基本工作流程，則可以在 DevOps 生命週期的每個階段看到 GitLab 中可用的功能。

圖片來源: 用 GitLab 做 CI/CD 是什麼感覺，太強了

1. Verify

• 通過持續整合自動構建和測試你的應用程式
• 使用 GitLab 程式碼質量（GitLab Code Quality）分析你的原始碼質量
• 通過瀏覽器效能測試（Browser Performance Testing）確定程式碼更改對效能的影響
• 執行一系列測試，比如 Container Scanning，Dependency Scanning，JUnit tests
• 用 Review Apps 部署更改，以預覽每個分支上的應用程式更改

2. Package

• 用 Container Registry 儲存 Docker 映象
• 用 NPM Registry 儲存 NPM 包
• 用 Maven Repository 儲存 Maven artifacts
• 用 Conan Repository 儲存 Conan 包

3. Release

• 持續部署，自動將你的應用程式部署到生產環境
• 持續交付，手動點選以將你的應用程式部署到生產環境
• 用 GitLab Pages 部署靜態網站
• 僅將功能部署到一個 Pod 上，並讓一定比例的使用者群通過 Canary Deployments 訪問臨時部署的功能（PS：即灰度釋出）
• 在 Feature Flags 之後部署功能
• 用 GitLab Releases 將釋出說明新增到任意 Git tag
• 使用 Deploy Boards 檢視在 Kubernetes 上執行的每個 CI 環境的當前執行狀況和狀態
• 使用 Auto Deploy 將應用程式部署到 Kubernetes 叢集中的生產環境

4. Others

• 通過 Auto DevOps 輕鬆設定應用的整個生命週期
• 將應用程式部署到不同的環境
• 安裝你自己的 GitLab Runner
• Schedule pipelines
• 使用安全測試報告（Security Test reports）檢查應用程式漏洞

參考資料
1. 前端工程化质量保障篇之什么是 CICD
2. 整合 Jenkins 來自動做前端效能測試
3. [Day29] CI /CD with GitLab CI
4. 前端工程化之CICD那点破事
5. 花半天时间，轻松打造前端CI/CD工作流
6. War of the CI servers – GitLab vs. GitHub vs. Jenkins
7. 理解 CI 與 CD 間的差異
8. 踏入 CI/CD 的世界 - 觀念篇
9. 架構師觀點: 你需要什麼樣的 CI / CD ?
10. DevOps、CI、CD 都是什麼鬼？
11. 用 GitLab 做 CI/CD 是什麼感覺，太強了
12. 什麼是 CI / CD ?