自動化運維持續整合
阿新 • • 發佈：2019-01-25
網際網路軟體的開發和釋出，已經形成了一套標準流程，最重要的組成部分就是持續整合（Continuous integration，簡稱 CI）。
持續整合的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，程式碼整合到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能整合。討論關注以下幾點：
- 持續整合概念的理解。
- 瞭解持續交付和持續部署。
- 熟悉持續整合操作流程。
一、概述
當前軟體的開發和釋出過程中，已經有了一套標準流程，最重要的組成部分就是持續整合（Continuous integration，簡稱 CI），為 Devops 平臺提供了一個良好的基礎。
開發團隊 -> 原始碼編碼（開發語言）-> 程式碼版本控制（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 容器 -> 測試
一場場看太麻煩？成為 GitChat 會員，暢享 1000+ 場 Chat ！點選檢視