《面試官別再問》什麼是持續整合、持續發佈（Continuous Integration & Continous Delivery） ?

為什麼我們需要 CI / CD ?
在比較小且快速的循環中，持續驗證系統開發結果 ，小部分小部分地儘早確認，期望開發產出能符合原始需求，或依據產出進行快速修正。 簡單來說就是儘量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。

CI的目的
降低風險。
減少人工手動的繁複程序。
可隨時產生一版可部署的版本。
增加系統透明度。
建立團隊信心。
什麼是持續性整合(CI)呢？持續性整合的目的為：針對軟體系統每個變動，能持續且自動地進行驗證。此驗證可能包含了：

建置 (build)
測試 (test)
程式碼分析 (source code analysis)
其他相關工作 (自動部署)
驗證完成後，進一步可以整合自動化發佈或部署 (Continuous Delivery / Continuous Deployment) 。透過此流程可以確保軟體品質，不會因為一個錯誤變動而產生錯誤結果或崩潰(Crash)。此流程中的各類工具，也會產生一些回饋給開發者或其他角色，包含網頁/報表等等，用來追蹤並改善軟體潛藏的問題。

工具的選擇
Jenkins
談到 CI，最廣為人知且老牌的工具是 Jenkins。Jenkins的功能完整，也提供了上千個外掛 (Plugins) 來對應各種開發語言與工具。Jenkins目前已發展到了 2.x 版，新版本中對於 Pipeline 概念及容器 (Container) 整合也趨於完整，是一套可以自訂運用的系統。但也因為其功能強大、客製程度高，上手需要一些時間。然而一旦流程被定義，並整合好相關環境，它可以發揮持續性整合威力，大幅增加開發生產力

Git — 版本管理
GitHub — 程式碼託管、審查
CircleCI — 自動化建置、測試、部署
Docker — 可攜式、輕量級的執行環境(使用 Docker，統一開發者、測試人員、以及產品的執行環境。)
AWS Elastic Beanstalk — 雲端平台
Slack — 團隊溝通、日誌、通知
建立 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 將主線建置後部署到測試環境提供給其他人員進行測試。