互聯網軟件的開發和發佈，已經形成了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱 CI）。
持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。
它的核心措施是，代碼集成到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。
討論關注以下幾點：
- 持續集成概念的理解。
- 瞭解持續交付和持續部署。
- 熟悉持續集成操作流程。
一、概述
持續集成流程：
開發團隊 -> 源代碼編碼（開發語言）-> 代碼版本控制（Gitlab） -> Docker 構建（創建鏡像）-> 靜態代碼分析（白盒測試）-> 自動化單元測試 -> 代碼覆蓋率（覆蓋率測試）-> Docker 版本（發佈到容器）-> 提供部署到測試環境 -> 自動化功能測試 -> 發佈報告 -> 生產部署
二、持續集成
- CI 過程：代碼編寫 -> 源代碼庫（GitHub or gitlab）-> CI 服務器（代碼構建、自動化測試、結果反饋【構建結果】）
- 涉及 CI 工具：Jenkins、Travis CI、TeamCity、Gitlab CI、CircleCI、Codeship 等，相關資料可以查詢對應的官網，其中應用廣泛的 Jenkins 和 Travis CI，Gitlab CI 是開源的 Rails 項目 GitLab 的一個組成部分，GitLab CI 能與 GitLab 完全集成，可以通過使用 GitLab API 輕鬆地作爲項目的鉤子。
持續集成構建目的：
- 及早發現集成錯誤，且由於修訂的內容較小所以易於追蹤，這可以節省專案的時間與成本。
- 避免發佈日期的前一分鐘發生混亂，當每個人都會嘗試爲他們所造成的那一點點不相容的版本做檢查。
- 當單元測試失敗或發生錯誤，若開發人員需要在不除錯的情況下還原程式碼庫到一個沒有問題的狀態，只需要放棄一小部份的更改（因爲集成的次數頻繁）。
- 讓“最新”的程式可保持可用的狀態供測試、展示或發佈用。
- 頻繁的提交程式碼會促使開發人員建立模組化，低複雜性的程式碼。
持續集成自動化測試目的：
- 強制執行頻繁的自動化測試紀律
- 當改變對全系統造成影響時立即反饋
- 自動化測試和持續性集成產生的軟件度量（如代碼覆蓋度量，代碼複雜度和功能完整性等）標準將開發人員集中在開發功能性，高品質的程式碼上，並幫助開發團隊發展。
持續集成存在的問題：
- 構建一個自動化測試套件需要大量的工作，包括不斷努力以覆蓋新功能，並依照特定情境進行程式碼修改，持續性集成可以在不需要測試套件下執行，但是必須手動和經常地完成，生產產品的品質保證成本將會提高。
- 構建構建系統需要一些工作，而且可能變得複雜，難以靈活修改。但是，也有一些開放源代碼的持續集成的專案軟件可以使用。
- 如果範圍很小或包含無法測試的舊版代碼，持續性集成不一定有價值。
- 增加的價值取決於測試的品質以及代碼的真實可測性。
- 較大的團隊意味著不斷將代碼添加到集成隊列中，因此追蹤交付（同時保持品質）很困難，而排隊可能會減慢所有人的進度。
- 通過一天的多次提交和合並，功能的部分代碼可以輕鬆推送，如此一來集成測試將會失敗直到整個功能開發完成。
三、持續交付（Continuous delivery，縮寫爲 CD）
持續集成 -> 再次測試 -> 結果發佈
-
CD 是一種軟件工程手法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件可以穩定、持續的保持在隨時可以釋出的狀況。它的目標在於讓軟件的建立、測試與釋出變得更快以及更頻繁。這種方式可以減少軟件開發的成本與時間，減少風險。
-
持續交付與 DevOps 的含義很相似，所以經常被混淆。但是它們是不同的兩個概念。DevOps 的範圍更廣，它以文化變遷爲中心，特別是軟件交付過程所涉及的多個團隊之間的合作（開發、運維、QA、管理部門等），並且將軟件交付的過程自動化。另一方面，持續交付是一種自動化交付的手段，關注點在於將不同的過程集中起來，並且更快、更頻繁地執行這些過程。因此，DevOps 可以是持續交付的一個產物，持續交付直接匯入 DevOps。
-
持續交付也與持續部署混淆。持續部署意味著所有的變更都會被自動部署到生產環境中。持續交付意味著所有的變更都可以被部署到生產環境中，但是出於業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。
四、持續部署（Continuous Deployment）
持續部署則是在持續交付的基礎上，把所有的變更自動部署到生產環境中。
- 通過以上步驟後，形成一個最終可以部署的版本（artifact），並將相關的版本打包成便於部署的文件包，如：tar.gz、jar 包、war 包等，發佈到生產環境。
- 架設 nexus 私服從內網獲取下載依賴庫，使用 nexus 私服僅在依賴庫第一次獲取時需要從中央倉庫或其他 maven 倉庫中獲取，之後便可從內網獲取。生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然後重新啓動應用。這方面的部署工具有 Ansible、Chef、Puppet 等。
- 通過配置管理工具將相應的程序包和配置文件及相關命令或腳本發佈到生產服務器，並根據相關的操作來完成這一部署過程。整個部署過程按照（如：ansible-playbook 執行 playbook.yml 來完成）
五、持續集成操作流程
編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署 -> 回滾
- 代碼編寫，完成代碼功能模塊。
- 構建，實現功能模塊構建測試，保證該模塊當前的可用狀態。
- 測試，單元測試和集成測試，保證各個功能模塊的完整性和穩定性。
- 交付，建立在CI基礎上，讓軟件的構建、測試與最終版本變得更快以及更頻繁。
- 部署，是在持續交付的基礎上，把部署到生產環境的過程自動化。
- 回滾，一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。
Docker + Jenkins + Git 發佈 Java 項目持續構建案例
Java 項目開發 -> 提交項目代碼 Git 容器 -> Jenkins 容器拉取項目代碼 -> Maven 編譯構建項目 -> Jenkins 發佈項目到 Tomcat 容器 -> 測試