CODING DevOps 系列第一課：基於開源工具鏈打造持續交付平臺

當下軟件發展趨勢

當今 IT 行業發展中比較流行的幾個技術，首先是微服務化，將原有的一個系統拆分紅多個，意味着有多個系統須要構建、測試、部署和運維。

第二個是敏捷開發模式，需求粒度更細化，要求一個可獨立部署單元快速開發、快速測試、快速部署上線，實現快速迭代。

還有一個就是容器化，隨着容器技術的快速發展，愈來愈多的應用遷移到了容器上。

這時候就會出現一些問題，若是當下軟件交付繼續使用傳統模式，就會須要花費大量的人力物力，同時有大量的重複部署任務，且交付沒法作到快速型。那麼有沒有一種更好的交付方式知足當下的軟件發展趨勢呢？答案確定是有的，正是在這樣的背景下，DevOps 橫空出世。

DevOps 簡介及特色

DevOps 是 Development 和 Operations 的組合，即開發、運維一體化。通俗地來講就是經過一系列工具及制定一些規範，儘量地實現軟件交付自動化，同時保障軟件交付質量。

DevOps 總得來講有如下幾大特色，首先是自動化，經過引入一些列工具，實現從需求到上線整個交付工程自動化，必要環節進行人工確認。

第二點是規範化，單有工具是不行的，須要一系列的規範支撐，好比版本管理規範、測試管理、測試數據管理等。

第三點是縮短交付週期，交付過程基本是一鍵式或者全自動，省去了中間沒必要要的環節，縮短了交付週期。

第四點是交付質量有保證，交付過程當中能夠引入靜態代碼掃描、單元測試、接口測試等環節，並對每一個環節設置質量門檻，下降了生產出現 bug 的機率，真正作到了防患於未然。

基於以上四個特色，咱們整個產品有了相應的提高，交付過程自動化解放了勞動力，又保障了交付質量，天然會帶來更大的收益。

工具集選型

版本控制系統

版本控制系統（VCS）也叫源代碼管理系統，顧名思義，提供最基本的版本控制功能，他會在文件修改的歷程中保留修改歷史，讓用戶能夠方便地查看該文件的修改歷史。而且能夠方便地讓用戶撤銷對文件的修改。

目前業界使用比較廣的版本控制系統主要有兩個，首先是 SVN，它是一個開放源代碼的版本控制系統，基於 CVS 發展而來，用於多我的共同開發同一個項目，共用資源。簡單、上手快，易操做，可是沒法實現分支管理，比較依賴網絡。

第二個是 GIT，它是一款免費、開源的分佈式版本控制系統，用於敏捷高效地處理任何或大或小的項目，做爲一個開源的分佈式版本控制系統，能夠有效、高速地處理各類項目版本管理，能夠實現很好的分支管理。

持續集成

持續集成這一塊也給你們介紹一款常見的工具——Jenkins，相信不少小夥伴都使用過，它是一個開源自動化服務器，做爲一個可擴展的自動化服務器，Jenkins 能夠用做簡單的 Cl 服務器，或者變成任何項目的持續交付中心。它的社區很是活躍，插件也較爲齊全，能夠集成打通需求管理、版本管理系統等。

持續測試

持續測試這塊咱們會有一個測試分層，分爲單元測試、接口測試、聯調測試。單元測試是方法級的測試，開發同事須要針對源碼編寫測試類，目的是爲了驗證功能代碼是否有問題，可使用 junit+jmock 實現，對接到 pipeline。

接口測試是針對外暴露的接口或者爲本系統提供服務的方法進行測試，須要編寫測試案例，能夠將 Jmeter 集成到 Jenkins 上實現接口自動化測試 及結果收集。

而聯調測試是指系統間連通性測試，須要人工介入。

持續部署

咱們部署的東西不只僅只涉及到應用部署包，還會牽扯到一些配置文件以及數據庫腳本。配置文件在大多數狀況下是與環境進行綁定的，每套環境使用一套配置文件，須要對配置文件作統一管理，發佈時選擇對應文件或者動態替換。

數據庫腳本須要將 SQL 變動文件歸入到版本管理系統中，發版時增量執行變動 SQL。

持續集成將構建包推送到製品庫中按照必定規範管理起來，部署時從製品庫中拉取對應版本的應用包部署。應用可能部署到物理機，有多是虛擬機、私有云或公有云。

分支策略方案

在整個交付環節中，版本控制是最重要的一塊，而版本控制又跟分支策略有關。若是前期分支策略作得很差的話，後期的版本控制確定是很糟糕的。只有前面作好了，後面纔有作好的可能。

分支管理的必要性

這裏相信小夥伴們都會有必定的瞭解，分支管理能夠幫助咱們避免代碼的丟失，若是沒有合理的分支管理，在某個功能尚未開發完，代碼推送到遠程會影響其餘功能，若是不推送到遠程倉庫中，本地數據丟失會致使代碼丟失。

同時，分支管理還能夠提升代碼質量。設置分支權限後，feature 分支向主幹分合並須要 master 角色 review 評審，保障了主幹分支代碼質量。

最後，隨着軟件的迭代，版本號也隨着變動，爲了追溯每一個版本的需求、變動集及線上 bug 修改，須要設計合理的分支策略並管理到需求和部署包。

合理分支策略的特色

首先，合理分支策略確定要符合業務場景。沒有最好的，只有合適的，設計符合本身業務場景的分支策略仍是最關鍵的。

第二，分支層次結構清晰。清晰的分支層次結構能更好地體現每一個分支的功能。

第三，避免形式主義。不該該爲了作分支管理而設計多層而設計多層分支，致使一次提交須要屢次合併，失去了高效支付效果。

最後是權限控制，須要對主幹分支設置相應權限，只有指定人員纔有權限合併，提升代碼質量。

Pipeline 簡介

全部的交付過程都是基於 pipeline 作的，pipeline 俗稱流水線，在 Jenkins 中也被稱爲 job，多個構建單元組成一條流水線，如代碼編譯、單元測試、代碼掃描組成一條 pipeline。編排一個 pipeline 有兩種方式：在 Jenkins 界面配置化實現以及編寫 Jenkinsfile 文件來實現環節的編排。

咱們主要推薦用 Jenkinsfile 進行編排，由於在當前的業務場景下，咱們的建議是「一切配置皆代碼」，這樣能保證咱們的全部配置是代碼化的，即便咱們的 Jenkins 服務器掛掉了或者被人刪掉了，咱們的 Jenkinsfile 也能存放在源代碼管理系統中。

Jenkinsfile 是 Jenkins 可識別的腳本文件，以代碼的形式將全部的構建步驟按照必定的語法寫入到該文件中，建立 pipeline 是指定該文件路徑。

咱們將在完整視頻中，繼續爲你們帶來幾種場景下的分支策略，以及 Pipeline 的設計、度量、反饋。點擊觀看完整視頻。