互聯(lián)網(wǎng)軟件的開發(fā)和發(fā)布氢拥，已經(jīng)形成了一套標準流程，最重要的組成部分就是持續(xù)集成（Continuous integration锨侯，簡稱 CI）嫩海。
持續(xù)集成的目的，就是讓產(chǎn)品可以快速迭代囚痴，同時還能保持高質量叁怪。
它的核心措施是，代碼集成到主干之前深滚，必須通過自動化測試奕谭。只要有一個測試用例失敗，就不能集成痴荐。
討論關注以下幾點：
- 持續(xù)集成概念的理解血柳。
- 了解持續(xù)交付和持續(xù)部署。
- 熟悉持續(xù)集成操作流程生兆。
一难捌、概述
持續(xù)集成流程：
開發(fā)團隊 -> 源代碼編碼（開發(fā)語言）-> 代碼版本控制（Gitlab） -> Docker 構建（創(chuàng)建鏡像）-> 靜態(tài)代碼分析（白盒測試）-> 自動化單元測試 -> 代碼覆蓋率（覆蓋率測試）-> Docker 版本（發(fā)布到容器）-> 提供部署到測試環(huán)境 -> 自動化功能測試 -> 發(fā)布報告 -> 生產(chǎn)部署
二、持續(xù)集成
- CI 過程：代碼編寫 -> 源代碼庫（GitHub or gitlab）-> CI 服務器（代碼構建鸦难、自動化測試栖榨、結果反饋【構建結果】）
- 涉及 CI 工具：Jenkins、Travis CI明刷、TeamCity婴栽、Gitlab CI、CircleCI辈末、Codeship 等纽哥，相關資料可以查詢對應的官網(wǎng)，其中應用廣泛的 Jenkins 和 Travis CI腊嗡，Gitlab CI 是開源的 Rails 項目 GitLab 的一個組成部分，GitLab CI 能與 GitLab 完全集成捅彻，可以通過使用 GitLab API 輕松地作為項目的鉤子。
持續(xù)集成構建目的：
- 及早發(fā)現(xiàn)集成錯誤鞍陨，且由于修訂的內容較小所以易于追蹤步淹，這可以節(jié)省專案的時間與成本。
- 避免發(fā)布日期的前一分鐘發(fā)生混亂诚撵，當每個人都會嘗試為他們所造成的那一點點不相容的版本做檢查缭裆。
- 當單元測試失敗或發(fā)生錯誤，若開發(fā)人員需要在不除錯的情況下還原程式碼庫到一個沒有問題的狀態(tài)寿烟，只需要放棄一小部份的更改（因為集成的次數(shù)頻繁）澈驼。
- 讓“最新”的程式可保持可用的狀態(tài)供測試、展示或發(fā)布用筛武。
- 頻繁的提交程式碼會促使開發(fā)人員建立模組化缝其，低復雜性的程式碼。
持續(xù)集成自動化測試目的：
- 強制執(zhí)行頻繁的自動化測試紀律
- 當改變對全系統(tǒng)造成影響時立即反饋
- 自動化測試和持續(xù)性集成產(chǎn)生的軟件度量（如代碼覆蓋度量徘六，代碼復雜度和功能完整性等）標準將開發(fā)人員集中在開發(fā)功能性内边，高品質的程式碼上，并幫助開發(fā)團隊發(fā)展待锈。
持續(xù)集成存在的問題：
- 構建一個自動化測試套件需要大量的工作假残，包括不斷努力以覆蓋新功能，并依照特定情境進行程式碼修改炉擅，持續(xù)性集成可以在不需要測試套件下執(zhí)行，但是必須手動和經(jīng)常地完成阳惹，生產(chǎn)產(chǎn)品的品質保證成本將會提高谍失。
- 構建構建系統(tǒng)需要一些工作，而且可能變得復雜莹汤，難以靈活修改快鱼。但是，也有一些開放源代碼的持續(xù)集成的專案軟件可以使用纲岭。
- 如果范圍很小或包含無法測試的舊版代碼抹竹，持續(xù)性集成不一定有價值。
- 增加的價值取決于測試的品質以及代碼的真實可測性止潮。
- 較大的團隊意味著不斷將代碼添加到集成隊列中窃判，因此追蹤交付（同時保持品質）很困難，而排隊可能會減慢所有人的進度喇闸。
- 通過一天的多次提交和合并袄琳，功能的部分代碼可以輕松推送询件，如此一來集成測試將會失敗直到整個功能開發(fā)完成。
三唆樊、持續(xù)交付（Continuous delivery宛琅，縮寫為 CD）
持續(xù)集成 -> 再次測試 -> 結果發(fā)布
CD 是一種軟件工程手法，讓軟件產(chǎn)品的產(chǎn)出過程在一個短周期內完成逗旁，以保證軟件可以穩(wěn)定嘿辟、持續(xù)的保持在隨時可以釋出的狀況。它的目標在于讓軟件的建立片效、測試與釋出變得更快以及更頻繁红伦。這種方式可以減少軟件開發(fā)的成本與時間，減少風險堤舒。
持續(xù)交付與 DevOps 的含義很相似色建，所以經(jīng)常被混淆。但是它們是不同的兩個概念舌缤。DevOps 的范圍更廣箕戳，它以文化變遷為中心，特別是軟件交付過程所涉及的多個團隊之間的合作（開發(fā)国撵、運維陵吸、QA、管理部門等）介牙，并且將軟件交付的過程自動化环础。另一方面线得，持續(xù)交付是一種自動化交付的手段募狂，關注點在于將不同的過程集中起來祸穷，并且更快雷滚、更頻繁地執(zhí)行這些過程揭措。因此绊含，DevOps 可以是持續(xù)交付的一個產(chǎn)物逃顶，持續(xù)交付直接匯入 DevOps以政。
持續(xù)交付也與持續(xù)部署混淆。持續(xù)部署意味著所有的變更都會被自動部署到生產(chǎn)環(huán)境中抖誉。持續(xù)交付意味著所有的變更都可以被部署到生產(chǎn)環(huán)境中，但是出于業(yè)務考慮我磁，可以選擇不部署夺艰。如果要實施持續(xù)部署，必須先實施持續(xù)交付。
四、持續(xù)部署（Continuous Deployment）
持續(xù)部署則是在持續(xù)交付的基礎上巷屿，把所有的變更自動部署到生產(chǎn)環(huán)境中嘱巾。
- 通過以上步驟后篙螟，形成一個最終可以部署的版本（artifact）问拘，并將相關的版本打包成便于部署的文件包绪杏，如：tar.gz蕾久、jar 包僧著、war 包等霹抛，發(fā)布到生產(chǎn)環(huán)境杯拐。
- 架設 nexus 私服從內網(wǎng)獲取下載依賴庫，使用 nexus 私服僅在依賴庫第一次獲取時需要從中央倉庫或其他 maven 倉庫中獲取顶滩，之后便可從內網(wǎng)獲取。生產(chǎn)服務器將打包文件仅醇，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄叶摄，然后重新啟動應用。這方面的部署工具有 Ansible唆铐、Chef顺少、Puppet 等脆炎。
- 通過配置管理工具將相應的程序包和配置文件及相關命令或腳本發(fā)布到生產(chǎn)服務器，并根據(jù)相關的操作來完成這一部署過程氓辣。整個部署過程按照（如：ansible-playbook 執(zhí)行 playbook.yml 來完成）
五秒裕、持續(xù)集成操作流程
編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署 -> 回滾
- 代碼編寫，完成代碼功能模塊钞啸。
- 構建几蜻，實現(xiàn)功能模塊構建測試，保證該模塊當前的可用狀態(tài)体斩。
- 測試梭稚，單元測試和集成測試，保證各個功能模塊的完整性和穩(wěn)定性絮吵。
- 交付弧烤，建立在CI基礎上，讓軟件的構建蹬敲、測試與最終版本變得更快以及更頻繁暇昂。
- 部署，是在持續(xù)交付的基礎上伴嗡，把部署到生產(chǎn)環(huán)境的過程自動化急波。
- 回滾，一旦當前版本發(fā)生問題闹究，就要回滾到上一個版本的構建結果幔崖。最簡單的做法就是修改一下符號鏈接食店，指向上一個版本的目錄渣淤。
Docker + Jenkins + Git 發(fā)布 Java 項目持續(xù)構建案例
Java 項目開發(fā) -> 提交項目代碼 Git 容器 -> Jenkins 容器拉取項目代碼 -> Maven 編譯構建項目 -> Jenkins 發(fā)布項目到 Tomcat 容器 -> 測試
