持續集成與devops

持續集成

持續集成

    持續集成（Continuous integration，簡稱CI），簡單的說持續集成就是頻緊地（一天屢次）將代碼集成到主幹，它的好處主要有兩個：

　　一、快速發現錯誤。每完成一次更新，就集成到主幹，能夠快速發現錯誤，定位錯誤也比較容易。

　　二、防止分支大幅偏離主幹。若是不是常常集成，主幹又在不斷更新，會致使之後集成的難度變大，甚至難以集成。

　　持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。

持續交付

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

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

持續部署

    持續部署（continuous deployment）是持續交付的下一步，指的是代碼經過評審之後，自動部署到生產環境。持續部署的目標是，代碼在任什麼時候刻都是可部署的，能夠進入生產階段。持續部署的前提是能自動化完成測試、構建、部署等步驟。注：持續交付不等於持續集成。

持續集成的通常流程

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

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

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

三、構建：經過第一輪測試，代碼就能夠合併進主幹，就算能夠交付了…

    交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換爲能夠運行的實際代碼，好比安裝依賴，配置各類資源（樣式表、J5腳本、圖片）等等。經常使用的構建工具以下。jeknins、Travis、codeship等。

四、測試（第二輪）

    構建完成，就要進行第二輪測試。若是第一輪已經涵蓋了全部測試內容，第二輪能夠省略，固然，這時構建步驟也要移到第一輪測試前面。第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要作端對端測試.全部測試以自動化爲主，少數沒法自動化的測試用例，就要手工跑。

五、部署

    經過了第二輪測試，當前代碼就是一個能夠直接部署的版本（artifact）。將這個版本的全部文件打包（tarfilename.tar」）存檔，發到生產服務器。生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號連接（symlink）指向目錄

認識 DevOps

DevOps是什麼

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

    目前對DevOps有太多的說法和定義，不過它們都有一個共同的思想：「解決開發者與運維者之間曾經不可逾越的鴻溝，加強開發者與運維者之間的溝通和交流」。而我我的認爲，DevOps能夠用一個公式表達：文化觀念的改變+自動化工具=不斷適應快速變化的市場。

強調：DevOps是一個框架，是一種方法論，並非一套工具，他包括一系列的基本原則和實踐，其核心價值在於如下兩點：

更快速地交付，響應市場的變化。

更多地關注業務的改進與提高。爲何須要DevOps？

一、產品選代

    在現實工做中，每每都是用戶不知道本身想要什麼，可是當咱們設計完一個產品後，他後告訴咱們他們不須要什麼，這樣咱們的產品須要反覆的選代，並且過程多是曲折的，那咱們有什麼好的辦法快速的交付價值，靈活的響應變化呢？答案就是Devops。由於Devops是面向業務目標，助力業務成功的最佳實踐。

二、技術革新

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

DevOps如何落地

落實DevOps的指導思想：

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

咱們來看一張來自devops 經典著做《success with enterprise dev-ops whitepaper》的介紹圖：

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

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

經過技術工具，把傳統的手工操做轉變爲自動化流程，這不只有利於提升產品開發、運維部

置的效率，還將減小人爲因素引發的失誤和事故，提前發現問題並及時地解決問題

DepOps在落地實施過程當中常常會遇到的問題

人手緊缺

跨部門協做，前期溝通培訓成本高

前期投入工做量大見效少。

DevOps技術棧

敏捷管理工具

  Trellor、Teambition、Worktile、Tower

產品&質量管理。

  confluence、禪道、Jira、Bugzila.

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

代碼倉庫管理

Git、Gitlab、Github

    Git是一個開源的分佈式版本控制系統；Gitlab和Github是用於倉庫管理系統的開源項目，它們使用Git做爲代碼管理工具，並在此基礎上搭建起來的web服務。咱們主要使用的是Git和Gitlab。

自動化構建腳本

    Gradle、Maven、SBT、ANT

慮擬機與容器化

    VMware、VirtualBox、Vagrant、Docker

持續集成（CI）&持續部署（CD）

    Jenkins、Hudson、Travis CI、Circle CI

  Jenkins是一個開源軟件項目，是基於Java開發的一種持續集成工具，用於監控持續重複的工做，日在提供一個開放易用的軟件平臺，使軟件的持續集成變成可能，它的前身爲Hudson。Travis CI是目前新興的開源持續集成構建項目，它與jenkins很明顯的區別在於採用yaml格式，簡潔清新獨樹一幟。

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

自動化測試

Appium

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

Selenium

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

Mock測試

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

消費者驅動契約測試

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

自動化運維工具

Ansible、Puppet、Chef、Saltstack

監控管理工具

Zabbix

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

ELKStack日誌分析系統。

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

雲監控（如Amazon CloudWatch）

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