持續集成（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平臺舒暢...
未完待續。