持續集成（Continuous integration）

1、基本概念

一、持續集成

　　持續集成（Continuous integration，簡稱CI），簡單來講持續集成就是頻繁地（一天屢次）將代碼集成到主幹。

　　每次集成都經過自動化的構建（包括編譯、發佈、自動化測試）來驗證，從而儘快地發現集成錯誤。

　　

　　持續集成強調開發人員提交了新代碼以後，馬上進行構建、（單元）測試。根據測試結果，能夠肯定新代碼和原有代碼可否正確地集成在一塊兒。

　　持續集成的好處：

• 快速發現錯誤，每完成一點更新，就集成到主幹，能夠快速發現錯誤，定位錯誤也比較容易；
• 防止分支大幅偏離主幹，若是不常常集成，主幹又在不斷更新，會致使之後集成的難度變大，甚至難以集成。

　　持續集成的目的：　　

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

　　持續集成並不能消除 Bug，而是讓它們很是容易的發現和改正。

二、持續交付

　　持續交付（Continuous delivery）指的是：頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。若是評審經過，代碼就進入生產階段。

　　

　　持續交付能夠看做持續集成的下一步。它強調的是，無論怎麼更新，軟件是隨時隨地能夠交付的。

三、持續部署

　　持續部署（Continuous deployment）是持續交付的下一步，指的是代碼經過評審之後，自動部署到生產環境。

　　

　　持續部署的目標是：代碼在任什麼時候候都是能夠部署的，能夠進入生產階段，持續部署的前提是能自動化完成測試、構建、部署等步驟。

四、持續交付和持續部署的區別

　　CD是持續交付和持續部署，可是持續交付不等於持續部署。持續部署則是在持續交付的基礎上，把部署到生產環境的過程自動化。具體區別參考下圖：

　　

2、持續集成的通常流程

　　根據持續集成的設計，代碼從提交到生產，整個過程有如下幾步：

（1）提交

　　流程的第一步，是開發者向代碼倉庫提交代碼。全部後面的步驟都始於本地代碼的一次提交（commit）。

（2）測試（第一輪）

　　代碼倉庫對commit操做配置了鉤子（hook），只要提交代碼或者合併進主幹，就會跑自動化測試。

（3）構建

　　經過第一輪測試，代碼就能夠合併進主幹，就算能夠交付了。

　　交付後，就先今夕構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換爲能夠運行的實際代碼，好比安裝依賴，配置各類資源（樣式表、JS腳本、圖片）等等。

　　經常使用的構建工具主要是：jeknins、Travis、codeship等。

（4）測試（第二輪）

　　構建完成，就要進行第二輪測試。若是第一輪已經涵蓋了全部測試內容，第二輪能夠省略，固然，這時構建步驟也要移到第一輪測試前面。

　　第二輪是全面測試，單元測試和繼承測試都會跑，有條件的話，也要作端對端測試。全部測試以自動化爲主，少數沒法自動化的測試用例，就要人工跑。

（5）部署

　　經過第二輪測試，當前代碼就是一個能夠直接部署的版本（artifact）。將這個版本的全部文件打包（tar filename.tar *）存檔，發到生產服務器。

　　生產服務器將打包文件，解包成本地的一個目錄，再講運行路徑的符號連接（symlink）指向這個目錄，而後從新啓動應用。

　　這方面的部署工具備Ansible、Chef、Puppet等。

（6）回滾

　　一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的作法就是修改一下符號連接，指向上一個版本的目錄。

3、認識DevOps 

一、DevOps是什麼？

　　DevOps 一詞的來自於 Development（開發） 和 Operations（運維） 的組合，突出重視軟件開發人員和運維人員的溝通合做，經過自動化流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。

　　目前對 DevOps 有太多的說法和定義，不過它們都有一個共同的思想：「解決開發者與運維者之間曾經不可逾越的鴻溝，加強開發者與運維者之間的溝通和交流」。

　　DevOps能夠用一個公式表示：文化觀念的改變+自動化工具 = 不斷適應快速變化的市場。

　　強調：DevOps是一個框架，是一種方法論，並非一套工具，它包括一系列的基本原則和實踐。

　　DevOps的核心價值：

• 更快速地交付，響應市場的變化；
• 更多地關注業務的改進和提高。

二、爲何須要DevOps?

（1）產品迭代 

　　在現實工做中，每每都是用戶不知道本身想要什麼，可是當咱們設計完一個產品後，他會告訴咱們他們不須要什麼，這樣咱們的產品須要反覆的迭代，並且過程多是曲折的，那咱們有什麼好辦法快速的交付價值，靈活的響應變化呢？

　　答案就是DevOps，由於DevOps是面向業務目標，助力業務成功的最佳實踐。

（2）技術革新

　　如今的IT技術架構隨着系統的複雜化不斷的革新，從最初全部服務在一個系統中，發展到如今的微服務架構、從純手動操做到全自動流程、從單臺物理機到雲平臺。

　　

三、DevOps如何落地？

　　落實DevOps的指導思想

　　高效的協做和溝通、自動化流程和工具、迅速敏捷的開發、持續交付和部署、不斷學習和創新。

　　下面是一張來自 devops 經典著做《success with enterprise dev-ops whitepaper》的介紹圖。

　　

　　敏捷管理：一支訓練有素的敏捷開發團隊是成功實施DevOps的關鍵。

　　根據康威定律：軟件團隊開發的產品是對公司組織架構的反映。

　　持續交付部署：實現應用程序的自動化構建、部署、測試和發佈。

　　經過技術工具，把傳統的手工操做轉變爲自動化流程，這不只有利於提升產品開發、運維部署的效率，還將減小人爲因素引發的失誤和事故，提前發現問題並及時地解決問題，這樣也保證了產品的質量。下圖展現了DevOps自動化的流程：

　　

　　IT服務管理（ITSM），它是傳統的「IT管理」轉向爲「IT服務」爲主的一種模式，前者可能更關注具體服務器管理、網絡管理和系統軟件安裝部署等工做；然後者更關注流程的規範化、標準化，明肯定義各個流程的目標和範圍、成本和效益、運營步驟、關鍵成功因素和績效指標、有關人員的責權利，以及各個流程之間的關係等，好比創建線上事故解決流程、服務配置管理流程等； 

　　精益管理：創建一個流水線式的 IT 服務鏈，打通開發與運維的鴻溝，實現開發運維一體化的敏捷模式。

　　精益生產主要來源於豐田生產方式（TPS）的生產哲學，它以下降浪費、提高總體客戶價值而聞名，它主要利用優化自動化流程來提升生產率、下降浪費。因此精益生產的精髓是即時制（JIT）和自動化（Jidoka）。

　　精益管理貫穿於整個DevOps階段，它鼓勵主動發現問題，不斷的優化流程，從而達到持續交付、快速反饋、下降風險和保障質量的目的。

四、實施DevOps的具體方法

（1）創建快速敏捷的團隊

　　按照業務功能劃分團隊，創建溝通羣組，設置產品負責人（一個策劃人員）、Scrum Master（咱們通常選擇測試人員擔任，測試驅動開發模式）和開發者團隊（前端工程師、後端工程師、測試各一名），造成以下的組織結構和系統構架：

　　 

（2）實現自動化的流程

　　直接看圖說話吧，如下爲一個完整DevOps的Pipeline：

　　

• 提交：工程師將代碼在本地測試後，提交到版本控制系統，如Git代碼倉庫中。
• 構建：持續整合系統（如Jenkins CI），在檢測到版本控制系統更新時，便自動從Git代碼倉庫里拉取最新的代碼，進行編譯、構建。
• 單元測試：Jenkins完成編譯構建後，會自動執行指定的單元測試代碼。
• 部署到測試環境：在完成單元測試後，Jenkins能夠將應用程序部署到與生產環境相近的測試環境中進行測試。
• 預生產環境測試：在預生產測試環境裏，能夠進行一些最後的自動化測試，例如使用Appium自動化測試工具進行測試，以及與實際狀況相似的一些測試可由開發人員或客戶人員手動進行測試。
• 部署到生產環境：經過全部測試後，即可以使用灰度更新將最新的版本部署到實際生產環境裏。

（3）DevOps在落地實施過程當中常常會遇到的問題

　　人手緊缺；跨部門協做，前期溝通培訓成本高；前期投入工做量大見效少。

五、DevOps技術棧 

（1）敏捷管理工具 

　　Trello、Teambition、Worktile、Tower

（2）產品&質量管理 

　　confluence、禪道、Jira、Bugzila。

　　其中 confluence 和禪道主要是產品的需求、定義、依賴和推廣等的全面管理工具；而 Jira 和 Bugzilla 是產品的質量管理和監控能力，包括測試用例、缺陷跟蹤和質量監控等。

　　目前使用Jira 和 禪道較多。

（3）代碼倉庫管理

　　Git、Gitlab、Github.

　　Git是一個開源的分佈式版本控制系統；

　　Gitlab 和 Github 是用於倉庫管理系統的開源項目，它們使用Git做爲代碼管理工具，並在此基礎上搭建起來的web服務。

（4）自動化構建腳本

　　Gradle、Maven、SBT、ANT

（5）虛擬機和容器化　　

　　VMware、VirtualBox、Vagrant、Docker

（6）持續集成(CI)&持續部署(CD)

　　Jenkins、Hudson、Travis CI、CircleCI。

　　Jenkins 是一個開源軟件項目，是基於 Java 開發的一種持續集成工具，用於監控持續重複的工做，旨在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能，它的前身爲Hudson。

　　Travis CI 是目前新興的開源持續集成構建項目，它與 jenkins 很明顯的區別在於採用 yaml 格式，簡潔清新獨樹一幟。

　　CircleCI 是一個 web 應用開發者提供服務的持續集成平臺，主要爲開發團隊提供測試，持續集成，以及代碼部署等服務。

（7）自動化測試

• Appium

  Appium是一個移動端的自動化框架，可用於測試原生應用，移動網頁應用和混合型應用，且是跨平臺的。可用於IOS和Android以及firefox的操做系統。

• Selenium

  Selenium 測試直接在瀏覽器中運行，就像真實用戶所作的同樣。Selenium 測試能夠在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中運行。

• Mock測試

  Mock測試就是在測試過程當中，對於某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來建立以便測試的測試方法。這個虛擬的對象就是Mock對象，Mock對象就是真實對象在調試期間的代替品。Java中的Mock框架經常使用的有EasyMock和Mockito等。

• 消費者驅動契約測試

  契約測試是一種針對外部服務的接口進行的測試，它可以驗證服務是否知足消費方期待的契約。當一些消費方經過接口使用某個組件的提供的行爲時，它們之間就產生了契約。這個契約包含了對輸入和輸出的數據結構的指望，性能以及併發性。而PACT是目前比較流的消費者驅動契約測試框架。

（8）自動化運維工具

• Ansible

• Puppet

• Chef

　　IT運維自動化是指將IT運維中平常的、大量的重複性工做自動化，把過去的手工執行轉爲自動化操做。自動化是IT運維工做的昇華，IT運維自動化不單純是一個維護過程，更是一個管理的提高過程，是IT運維的最高層次，也是將來的發展趨勢。下圖爲經常使用自動化運維工具對比：

　　

（9）監控管理工具

• Zabbix

  Zabbix是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級開源解決方案。

• ELK Stack日誌分析系統

  ELK Stack是開源日誌處理平臺解決方案，背後的商業公司是Elastic。它由日誌採集解析工具 Logstash、基於 Lucene 的全文搜索引擎 Elasticsearch、分析可視化平臺 Kibana三部分組成。

• 雲監控（如Amazon CloudWatch）

  Amazon CloudWatch 是一項針對 AWS 雲資源和在 AWS 上運行的應用程序進行監控的服務。您可使用 Amazon CloudWatch 收集和跟蹤各項指標、收集和監控日誌文件、設置警報以及自動應對 AWS 資源的更改