代碼不是技術團隊的傳遞物，可運作的軟體才是
雖然我們在同一個時代寫代碼做開發，但技術實踐層面，不同的團隊卻仿佛生活在不同的年代。
把開發工作流程分為以下幾個階段：
編碼 -> 建構 -> 內建 -> 測試 -> 傳遞 -> 部署
「持續內建（Continuous Integration）」、「持續傳遞（Continuous Delivery）」和「持續部署（Continuous Deployment）」有着不同的軟體自動化傳遞周期。
持續 (Continuous)：不斷的擷取回報，響應回報。
內建 (Integration)：當我們在一個團隊中工作的時候。把不同人的代碼放在一起，使之成為一個可工作軟體的過程叫內建。編譯、測試、打包；
部署 (Deployment)：應用元件或基本設施的代碼或配置變更在産品環境生效稱為“部署”；
釋出 (Release)：具有業務影響的功能變化對最終使用者可見稱為“釋出”。
傳遞 (Delivery)：可以了解為從 Deployment 到 Release之間的階段，更多的強調的是一種能力。開發有能力頻繁的部署，業務有能力随時釋出。
名詞說的那麼多，扯的天花亂墜也沒什麼卵用，達到實際的效果才行。沒有标準都是紙上談兵
原則：開發人員送出代碼到git，剩下的事情軟體自動完成，打開浏覽器可以直接看到程式界面
讓産品快速可以快速疊代，同時還能保持高品質。它的核心措施是，代碼內建到主幹之前，必須通過自動化測試。
隻要有一個測試用例失敗，就不能內建。
"持續內建并不能消除bug，而是讓它們非常容易發現和改正。"
全面的自動化測試：這是實踐持續內建&持續部署基礎，同時，選擇合适的自動化測試工具也極其重要；
靈活的基礎設施：容器，虛拟機存在讓開發人員和QA人員不必再大費周折；
版本控制工具：如Git、SVN
自動化建構和軟體釋出流程工具：如Jenkins
回報機制：如建構/測試失敗，可以快速回報到相關負責人，以盡快解決達到一個穩定的版本。
"快速失敗"，對産品沒有風險情況下進行測試，并快速響應
最大限度減少風險，降低錯誤代碼修複的成本；
将重複性的手工流程自動化，讓工程師更加專注代碼；
保持頻繁部署，快速生成可部署軟體；
提高項目的能見度，友善團隊成員了解項目的進度和成熟度
增強開發人員對軟體産品的信心，幫助建立更好工程師文化
快速發現錯誤。沒完成一點更新，就內建到主幹，可以快速發現錯誤，定位錯誤也比較容易
防止分支大幅偏離主幹。如果不是經常內建，主幹又在不斷更新，會導緻以後內建的難度很大，甚至難以內建
選擇合适的內建系統，私有部署還是托管型持續內建系統。
條件：
團隊運作的基礎設施
內建系統資源投入力度
Maven、Gradle或Jenkins，他們的特點是自由開源，且文檔支援廣泛。優點在于建構環境有完全的控制權，
能夠實作完全的定制。但需要搭建環境和配置、維護成本高，需要買專門的機器，話費較多的人力物力且更新遷移
更新高；
CircleCI：https://circleci.com/
Codeship： https://www.cloudbees.com/products/codeship
TravisCI ：https://travis-ci.org/
FlowCI：https://github.com/FlowCI/docs，https://flowci.github.io/#download
整體而言，目前大部分公司選擇的是Jenkins，随着雲服務，Docker，Saas的普及，越來越多的企業選擇托管型內建系統。
選擇持續內建系統隻是持續內建應用的其中一步，還需要建立合适的內建文化比如代碼品質管控、測試文化。做好持續內建，可為持續傳遞與持續部署打好堅實基礎。
** 邁向持續內建**
Daily Build 每日建構
開發與內建合二為一
盡早送出代碼去內建
盡早把代碼和已有代碼內建到一起，而不應該等着所有代碼都開發完了，再去做送出
通過盡早內建。減少改動量，降低內建難度
執行同樣的操作，本地環境會快于CI伺服器環境
隻有CI伺服器處于綠色的狀态才能送出代碼，用好本地建構腳本（build script），保證各種各樣的檢查都可以在本地環境執行
流程的第一步，是開發者向代碼倉庫送出代碼。所有後面的步驟都始于本地代碼的一次送出.
代碼倉庫對commit操作配置了鈎子（hook），隻要送出代碼或者合并進主幹，就會跑自動化測試。
單元測試：針對函數或子產品的測試
內建測試：針對整個産品某個功能
通過第一輪測試，代碼可以合并進主幹，就算可以傳遞了
傳遞後，就先進行建構（build），再進入第二輪測試。所謂建構，指的是将源代碼轉換成可運作的實際代碼，比如安裝依賴，配合各種資源（樣式、JS腳本、圖檔）等等。
常用的建構工具：
Jenkins
Travis
Codeship
Strider
Jenkins宇Strider是開源軟體，Travis和Codeship對于開源項目可以免費使用。它們都會将建構和測試，在一次運作中執行完成。
建構完成，就要進行第二輪測試。如果第一輪已經覆寫了所有測試内容，第二輪可以省略，當然，這時建構步驟也要移到第一輪測試前面。
第二輪是全面測試，單元測試和內建測試都會跑，有條件的話，也要做端到端的測試。所有測試以自動化為主，少數無法自動化的測試用例，就要人工跑
需要強調的是，新版本的每一個更新點都必須要測試到。如果測試的覆寫率不高，進入後面的部署階段，很可能出現嚴重的問題。
通過了第二輪測試，目前代碼就是一個可以直接部署的版本。将這個版本的所有檔案打包存檔，發到生産伺服器。
生産伺服器将打封包件，解包成本地的一個目錄，在将運作路徑的符号連結指向目錄，然後重新啟動應用。這方面的部署工具有Ansible，Chef，Puppet等。
一旦目前版本發生問題，就要復原到上一個版本的建構結果。最簡單的做法就是修改一下符号連結，指向上一個版本目錄。