持續集成

互聯網軟件的開發和發佈，已經造成了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱 CI）。

持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹以前，必須經過自動化測試。只要有一個測試用例失敗，就不能集成。討論關注如下幾點：

持續集成概念的理解。
瞭解持續交付和持續部署。
熟悉持續集成操做流程。
1、概述

當前軟件的開發和發佈過程當中，已經有了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱 CI），爲 Devops 平臺提供了一個良好的基礎。

開發團隊 -> 源代碼編碼（開發語言）-> 代碼版本控制（Gitlab） -> Docker 構建（建立鏡像）-> 靜態代碼分析（白盒測試）-> 自動化單元測試 -> 代碼覆蓋率（覆蓋率測試）-> Docker 版本（發佈到容器）-> 提供部署到測試環境 -> 自動化功能測試 -> 發佈報告 -> 生產部署

 

2、持續集成

 

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 輕鬆地做爲項目的鉤子。
持續集成構建目的：

及早發現集成錯誤，且因爲修訂的內容較小因此易於追蹤，這能夠節省專案的時間與成本。
避免發佈日期的前一分鐘發生混亂，當每一個人都會嘗試爲他們所形成的那一點點不相容的版本作檢查。
當單元測試失敗或發生錯誤，若開發人員須要在不除錯的狀況下還原程式碼庫到一個沒有問題的狀態，只須要放棄一小部份的更改（由於集成的次數頻繁）。
讓「最新」的程式可保持可用的狀態供測試、展現或發佈用。
頻繁的提交程式碼會促使開發人員創建模組化，低複雜性的程式碼。
持續集成自動化測試目的：

強制執行頻繁的自動化測試紀律
當改變對全系統形成影響時當即反饋
自動化測試和持續性集成產生的軟件度量（如代碼覆蓋度量，代碼複雜度和功能完整性等）標準將開發人員集中在開發功能性，高品質的程式碼上，並幫助開發團隊發展。
持續集成存在的問題：

構建一個自動化測試套件須要大量的工做，包括不斷努力以覆蓋新功能，並依照特定情境進行程式碼修改，持續性集成能夠在不須要測試套件下執行，可是必須手動和常常地完成，生產產品的品質保證成本將會提升。
構建構建系統須要一些工做，並且可能變得複雜，難以靈活修改。可是，也有一些開放源代碼的持續集成的專案軟件可使用。
若是範圍很小或包含沒法測試的舊版代碼，持續性集成不必定有價值。
增長的價值取決於測試的品質以及代碼的真實可測性。
較大的團隊意味著不斷將代碼添加到集成隊列中，所以追蹤交付（同時保持品質）很困難，而排隊可能會減慢全部人的進度。
經過一天的屢次提交和合並，功能的部分代碼能夠輕鬆推送，如此一來集成測試將會失敗直到整個功能開發完成。
3、持續交付（Continuous delivery，縮寫爲 CD）

持續集成 -> 再次測試 -> 結果發佈

CD 是一種軟件工程手法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件能夠穩定、持續的保持在隨時能夠釋出的情況。它的目標在於讓軟件的創建、測試與釋出變得更快以及更頻繁。這種方式能夠減小軟件開發的成本與時間，減小風險。
持續交付與 DevOps 的含義很類似，因此常常被混淆。可是它們是不一樣的兩個概念。DevOps 的範圍更廣，它以文化變遷爲中心，特別是軟件交付過程所涉及的多個團隊之間的合做（開發、運維、QA、管理部門等），而且將軟件交付的過程自動化。另外一方面，持續交付是一種自動化交付的手段，關注點在於將不一樣的過程集中起來，而且更快、更頻繁地執行這些過程。所以，DevOps 能夠是持續交付的一個產物，持續交付直接匯入 DevOps。
持續交付也與持續部署混淆。持續部署意味著全部的變動都會被自動部署到生產環境中。持續交付意味著全部的變動均可以被部署到生產環境中，可是出於業務考慮，能夠選擇不部署。若是要實施持續部署，必須先實施持續交付。

4、持續部署（Continuous Deployment）

持續部署則是在持續交付的基礎上，把全部的變動自動部署到生產環境中。

經過以上步驟後，造成一個最終能夠部署的版本（artifact），並將相關的版本打包成便於部署的文件包，如：tar.gz、jar 包、war 包等，發佈到生產環境。
架設 nexus 私服從內網獲取下載依賴庫，使用 nexus 私服僅在依賴庫第一次獲取時須要從中央倉庫或其餘 maven 倉庫中獲取，以後即可從內網獲取。生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號連接（symlink）指向這個目錄，而後從新啓動應用。這方面的部署工具備 Ansible、Chef、Puppet 等。
經過配置管理工具將相應的程序包和配置文件及相關命令或腳本發佈到生產服務器，並根據相關的操做來完成這一部署過程。整個部署過程按照（如：ansible-playbook 執行 playbook.yml 來完成）

5、持續集成操做流程

編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署 -> 回滾

代碼編寫，完成代碼功能模塊。
構建，實現功能模塊構建測試，保證該模塊當前的可用狀態。
測試，單元測試和集成測試，保證各個功能模塊的完整性和穩定性。
交付，創建在CI基礎上，讓軟件的構建、測試與最終版本變得更快以及更頻繁。
部署，是在持續交付的基礎上，把部署到生產環境的過程自動化。
回滾，一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的作法就是修改一下符號連接，指向上一個版本的目錄。

Docker + Jenkins + Git 發佈 Java 項目持續構建案例

Java 項目開發 -> 提交項目代碼 Git 容器 -> Jenkins 容器拉取項目代碼 -> Maven 編譯構建項目 -> Jenkins 發佈項目到 Tomcat 容器 -> 測試