為什麼我們需要 CI / CD ?
在比較小且快速的循環中，持續驗證系統開發結果 ，小部分小部分地儘早確認，期望開發產出能符合原始需求，或依據產出進行快速修正。 簡單來說就是儘量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。
CI的目的
- 降低風險。
- 減少人工手動的繁複程序。
- 可隨時產生一版可部署的版本。
- 增加系統透明度。
- 建立團隊信心。
什麼是持續性整合(CI)呢？持續性整合的目的為：針對軟體系統每個變動，能持續且自動地進行驗證。此驗證可能包含了：
- 建置 (build)
- 測試 (test)
- 程式碼分析 (source code analysis)
- 其他相關工作 (自動部署)
驗證完成後，進一步可以整合自動化發佈或部署 (Continuous Delivery / Continuous Deployment) 。透過此流程可以確保軟體品質，不會因為一個錯誤變動而產生錯誤結果或崩潰(Crash)。此流程中的各類工具，也會產生一些回饋給開發者或其他角色，包含網頁/報表等等，用來追蹤並改善軟體潛藏的問題。
工具的選擇
Jenkins
談到 CI，最廣為人知且老牌的工具是 Jenkins。Jenkins的功能完整，也提供了上千個外掛 (Plugins) 來對應各種開發語言與工具。Jenkins目前已發展到了 2.x 版，新版本中對於 Pipeline 概念及容器 (Container) 整合也趨於完整，是一套可以自訂運用的系統。但也因為其功能強大、客製程度高，上手需要一些時間。然而一旦流程被定義，並整合好相關環境，它可以發揮持續性整合威力，大幅增加開發生產力
建立 CI / CD 流程雛形
我們結合了 Git Flow + Protected Branch Flow 的開發流程，流程如下：
- 開發者 (Developer) 先開立 (create) 一個功能分支 (feature branch)。
- 開發者提交一個 Pull Request， SCM 系統會自動觸發 Jenkins 進行建置以及測試。這個觸發通常是經由 Webhook 來實現。
- 在軟體建置完成後，在 Jenkins 增加一個步驟來送出原碼掃瞄 (Code Scan) 的請求給 Sonarqube 系統。Sonarqube 則在完成程式碼掃瞄後將結果寫回 SCM 系統。
- 由於我們在 SCM 上連結了 Slack，每個步驟完成（成功或失敗）的通知便可以送到 Slack 群組。
- 原碼審核者 (Reviewer) 可以到 SCM 上查看這個Pull Request的相關訊息，搭配 Code Scan的結果決定是否將這個分支合併 (merge) 回主線(develop/master branch)。
- 分支合併可以觸發另一個 CI 工作，使 Jenkins 將主線建置後部署到測試環境提供給其他人員進行測試。
http://1.bp.blogspot.com/-ayMPUYipAYI/VTpPWTEljXI/AAAAAAAAkb8/vpw5-wr-BjQ/s1600/sequence-diagram.png
題外話(可能是一些基礎知識)
GitHub Flow : 利用 Pull Request 以及分支來完成代碼審查（Code Review）與環境配置，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。