【工程化】持續整合
持續整合（Continuous integration，簡稱CI）是軟體開發工程化的關鍵流程之一。
最近跟朋友做個練手的專案，用Jenkins進行持續整合和部署，相關的東西在這裡進行一些記錄。
剛接觸不多，一些東西還沒有完全理清楚，埋坑待填。
CI的概念
CI這個概念其實是比較模糊的。
這裡的“整合”，最早似乎是指程式碼的整合。
阮一峰-持續整合是什麼？ 對相關概念有所闡述。
具體而言，就是對提交到分支的程式碼進行較高頻率的構建、測試，通過後就“整合”到主幹。這個頻率通常為一日多次。
這篇文章提到的工作流在目前看來是比較罕見的，裡面解釋的持續整合跟我們現在常說的持續整合也有不小區別。
而現在說起持續整合，往往是指程式碼提交後，自動觸發自動化測試與構建的過程。這時對“整合”的解釋大體有兩種說法，一種是說，把測試、構建之類的步驟自動化地整合在一起；另一種說，通過測試、構建來判斷程式碼整合得是否成功。
總體而言，CI在現在的運用中，是在程式碼提交後觸發的檢查步驟，而不是程式碼提交前的前置步驟。程式碼提交這一行為，往往根據團隊的工作流進行具體定製，不會跟CI強繫結。
瀏覽網上資料的時候要注意，很多時候雖然大家說的都是持續整合這個詞，但由於隨時間的演化，其內涵可能有很大的不同。
CI的工具
CI的工具有很多，大體上分為兩大類。
一種是第三方平臺上的，比如你用github，相關的CI平臺就有Travis CI，Circle CI等。進行相關配置後，程式碼提交到github就能自動觸發，不需要自己部署伺服器，當然，這些CI服務通常是收費的。如果是開源專案會有一定的免費資源。
一種是自己部署的，比如Jenkins。這種其實不復雜，規定一個觸發方式，是定時觸發還是通過github的鉤子去觸發；然後自己寫個指令碼做測試、構建。完了之後想要部署的話也是自己寫指令碼來搞。Jenkins主要是對專案、版本、每次構建做下管理，提供UI讓我們進行一些配置。
這裡我只用過Jenkins，emmm，吐槽一下，上古介面，看起來就沒有商用CI平臺舒暢...
未完待續。