CI-持續集成（2）-軟件工業「流水線」技術實現（轉）

時間  2020-07-10
標籤 持續 集成 軟件 工業 流水線 技術 實現 简体版
原文   原文鏈接

1   概述

持續集成（Continuous Integration）是一種軟件開發實踐。在本系列文章的前一章節已經對其背景及理論體系進行了介紹。本小節則承接前面提出的理論構想進行具體的技術實現。css

《Google軟件測試之道》:html

"天天，Google都要測試和發佈數百萬個源文件，億萬行代碼。數以億計的構建動做會觸發幾百萬次的自動化測試，並在好幾十萬個瀏覽器實例上執行。面對這些看似不可能完成的任務，谷歌是如何測試的呢？"前端

但願看完此文章的人，可以本身找到本身的答案。python

 

2   主要環境及工具

  • Git代碼管理系統（如：GitOSC）
  • Linux操做系統（Ubuntu）
  • Jenkins系統軟件安裝包
  • Jenkins的Python語言的SDK
  • Python及 Tornado Web 框架

以上的技術選型，都是儘可能使用 開源 且 主流 的系統，這樣的好處以下：git

  • 節省軟件購置成本
  • 有豐富的參考資料
  • 有能力的企業或者我的能夠按照需求作自定義擴展

3   原理分析

在上一篇文章裏面，對持續集成繪製過一個基本的結構圖，以下：github

基本流程以下：web

  1. 開發人員推送代碼到Git瀏覽器

  2. Git通知Jenkins安全

  3. Jenkins開啓構建bash

  4. 構建完成開啓後續任務
    • 自動化測試
    • 自動化部署

  5. Jenkins通知自動化發佈系統

  6. 發佈系統持續後續的任務……

這裏面涉及的系統有：

  1. 代碼版本管理系統
  2. 自動化構建系統
  3. 自動化測試系統
  4. 自動化發佈系統

關於 自動化發佈系統 這個基本上屬於運維方面的內容，在互聯網產品領域情形和技術需求比較複雜，暫時不列入本部分的內容。可是Jenkins 可以有接口去通知相應的發佈系統，以達到 事件信息流的連續性

本文則主要從技術角度來將這些系統聯合起來。

4   Jenkins安裝及配置

4.1   下載和安裝

關於 Jenkins 的下載及安裝，能夠參考其官網。

直接下載Ubuntu/Debian版本，在Ubuntu服務器上安裝便可。

因爲過程比較簡單，網上相關教程不少，此處也再也不贅述。可是通常Jenkins安裝完畢後，最初的權限配置會比較繁瑣，因此本文重點從相應的使用場景出發，實現一個完整的帶權限配置的解決方案。

5   內網持續集成系統

對於只是在 內網 使用持續集成的團隊來講，權限的配置就相對簡單一些。由於只是在內網，因此能夠將權限的要求放鬆，只要保證公司網絡以外的人沒法訪問到 Jenkins 服務便可。

注意：若是要和git服務的webhook造成完整的事件流，則git服務也須要在內網，不然 構建事件 沒法被 代碼推送事件 給觸發。

5.1   權限配置

對 Jenkins 進行以下操做：

[系統管理]->[Configure Global Security]->[訪問控制]->[受權策略]->[項目矩陣受權策略]

對 匿名用戶 進行以下配置：

  • Overall: Read -> Enabled
  • Job: Read -> Enabled

具體配置界面以下：

注意：若是不這樣配置，則後面提到的基於git的構建觸發器將沒法經過調用指定的url接口來觸發構建。由於webhook只能構造 單次 簡單的http請求，沒法構造由多個請求組成的會話，故而沒法調用須要身份受權的接口。

5.2   構建觸發器

通常狀況下，構建都是以代碼的發佈做爲起始事件點，因此須要和git服務器創建事件關聯，在Jenkins具體的項目的配置界面中，對 構建觸發器 進行配置。

目前網絡上通常都是介紹的這種方式，具體的細節，此處就再也不贅述，感興趣的同窗能夠自行在網絡上搜索。

基本原理圖以下：

5.3   最終效果

能夠達到以下效果：

  • 開發人員向內網的git服務器推送代碼
  • git服務的webhook向內網jenkins發送消息並 觸發構建
  • Jenkins執行構建相關命令

以上的內網方案的特色以下：

  • 優勢：
    • 配置簡單
    • 不須要配置人員進行任何的開發活動
  • 缺點
    • 沒法限制匿名用戶的權限
    • 出於安全考慮，只能在內網使用

固然，對於 開發資源相對匱乏 的小團隊而言，推薦經過以上方法 快速搭建 本身的內部的持續集成系統，畢竟先快速生產本身的特點產品纔是最重要的事情。

6   公網持續集成系統

對於前面的 內網持續集成系統 的優勢和缺點都介紹以後，做爲一個以 開放爲主要精神 的互聯網團隊來講，確定是沒法知足這樣一個 封閉的內部網絡 系統的，因此下面就要隆重介紹 公網持續集成系統 。

對於 內網系統 在配置上進行了 偷懶 ，可是實際上卻在其它地方付出了 巨大的代價 ，這些代價包括：

  • 沒法使用市場上已經成熟的公網git服務(包括但不限於：bitbucket,github,git@osc)
  • 團隊成員的工做地點將受到限制，必須侷限於同一個內網環境中

因此，若是配置人員擁有必定的系統設計能力和開發能力，仍是建議搭建 公網持續集成系統 。

公網方案具備以下特色：

  • 缺點：
    • 須要配置人員具有系統設計能力和開發能力
  • 優勢：
    • 可以將系統以登陸受權的方式部署在公網
      • 未登陸的匿名用戶沒法查看任何項目信息
      • 登陸用戶能夠配置不一樣的權限
    • 可以做爲服務器來接受來自事件來觸發構建
      • 能夠經過公網git服務的webhook觸發
      • 能夠經過自定義的任何公網IT系統觸發（按鈕，短信，微信等等）

    • 可擴展性強，理論上能夠和任何的公共互聯網服務進行對接

6.1   權限配置

公網持續構建系統對權限控制有以下要求：

  • 未登陸的匿名用戶沒法查看任何項目信息
  • 登陸用戶能夠配置不一樣的權限

對 Jenkins 進行以下操做：

[系統管理]->[Configure Global Security]->[訪問控制]->[受權策略]->[項目矩陣受權策略]

能夠創建三類用戶並進行權限配置：

  • 普通用戶

    登陸後，能夠查看相應的項目的名稱及構建的狀態（主要是基本的查看功能）

  • 管理員用戶

    登陸後，能夠進行構建操做，對任務進行增長及刪除等等高級操做（主要是項目管理功能）

  • 匿名用戶

    未登陸用戶，不具有任何權限，只呈現登陸界面

有了這樣的登陸受權機制，就不用再使用網絡進行隔離了，此係統就能夠放心地放到公網服務器上了。

前面提到的內網系統的解決方案，主要緣由是：

  1. 基於git的webhook沒法對須要認證的 構建觸發器 接口請求發起有效構建請求
  2. 將 構建觸發器 接口設置爲不須要認證，會致使匿名用戶的權限過大

若是部署到公網，則須要解決如上的矛盾之處。一個比較好的思路就是：

  1. 按照要求配置好相應的用戶權限（見公網權限配置方案）
  2. 開發中間件來完成 構建API 的用戶登陸認證

6.2   構建觸發器

在兼顧Git的webhook的特色和Jenkins構建特性的狀況下，能夠提出以下所描述的解決方案：

使用web服務做爲中間件，來模擬用戶登陸：將原本須要多個請求組成的會話變成單一的Http請求（能夠在單次請求的url裏面加入受權的token），這樣就能夠被Git的webhook所調用。

基本原理圖以下：

主要的通信過程爲：

  1. Git Server 接收代碼並向 Web Server 發起單次Http請求（參數帶上token）
  2. Web Server 先向 Jenkins Server 發起認證受權請求
  3. Web Server 再向 Jenkins Server 發起構建請求，觸發構建

固然，因爲 Jenkins 提供了Pyhon語言的SDK，因此以上 步驟2和3其實能夠簡化爲對其SDK的調用了。

安裝方法：

1
pip  install  python-jenkins

最簡單的使用示例以下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# coding:utf-8
"""
jenkins相關的工具函數及配置
"""
from  dtlib.dtlog  import  dlog
import  jenkins
 
__author__  =  'harmo'
 
 
jenkins_url  =  'http://jenkins.xxxx.com'
jenkins_user  =  'jenkins_user'
jenkins_passwd  =  'jenkins_user_password'
 
 
def  build_job(project_name):
     """
     構建項目
     :param project_name: 項目名稱
     :return:
     """
     jen  =  jenkins.Jenkins(jenkins_url, username = jenkins_user, password = jenkins_passwd)
     jen.build_job(project_name)
     print ( "build %s succeed"  %  project_name)
 
if  __name__  = =  '__main__' :
     build_job( "your-project-name" )

開發人員只須要在本身的web程序裏面集成此SDK，並進行參數化，便可完成webhook和jenkins的中間件。

6.3   最終效果

能夠達到以下效果：

  • 接收git服務的webhook請求
  • 解析請求中代碼提供信息，包括但不限於：提交時間，提交人，分支，備註，項目名稱等等
  • 進行條件過濾，並觸發 Jenkins 進行自動構建（例如：本文是對release分支進行監控，來觸發構建）

使用中間件的好處是，對構建的事件有很好的訂製性，包括分支監控，提交人權限等等。固然，也能夠只使用最簡單的功能：只要有人向 release 分支提交了代碼，那麼就會觸發自動構建流程，這樣就完成了整個流程了。

固然，構建成功以後到發佈還有一些後續的流程，好比：

  1. 開發人員完成代碼，自測完畢後，推送代碼到 release 分支

  2. 觸發自動構建，構建成功，並生成構建產物

  3. 將構建產物發佈到 測試服務器

  4. 觸發自動化測試腳本
    • 若是測試不經過，發送消息給相關人員，終止後續流程
    • 若是測試經過，通知 自動化發佈系統

  5. 由 自動化發佈系統 完成構建產物向生產服務器發佈的過程

6.4   其它說明

在得知Jenkins有Python語言的SDK以前，其實還有個其它方法也可以完成登陸受權並調用構建接口。直接經過接口來模擬用戶登陸行爲（由於Jenkins登陸處不須要驗證碼），而後獲取登陸成功的sessionid ，以此做爲受權token來調用構建的接口。

具體的技術實現的代碼細節不在本文的討論內容中出現，只要瞭解登陸的原理，很容易就開發出來。

此處作一些說明的目的是，其實只要瞭解原理，即便官方沒有提供一些工具，仍然也是有辦法完成想要的功能的。

7   持續集成的應用場景

持續集成的平臺搭建完畢後，關於其可應用的項目也進行一些簡單的介紹。

基本上任何的軟件項目，從生產到最終發佈均可以劃分爲以下幾個過程：

  1. 代碼開發
  2. 構建生成發佈產物
  3. 發佈上線

不一樣類型項目，無非就是構建過程不一樣而已，本文也簡單的列舉一下幾類項目的應用方式的流程，關於具體的技術手段就由各人根據各自的項目去作相應的訂製開發了。

7.1   腳本類服務端項目

主要的表明有：Php，Python等等。

它們的構建產物就自己的源代碼，因此整個持續集成的過程以下：

  1. 開發人員發佈代碼到Git倉庫
  2. Jenkins同步代碼到本地（作好發佈產物的備份，方便回滾）
  3. 部署好測試服務器
  4. 執行自動化測試腳本
  5. 發佈到生產服務器或者駁回

7.2   須要編譯的服務端項目

主要的表明有：Java等。

過程以下：

  1. 開發人員發佈代碼到Git倉庫
  2. Jenkins同步代碼到本地，並使用構建工具（如：Ant等）生成字節碼的構建產物
  3. 將構建產物統一備份到相應目錄，作好發佈產物的備份，方便回滾
  4. 部署測試服務器
  5. 測試……
  6. 發佈……

7.3   Web前端項目

主要表明有：Javascript,css等。

過程以下：

  1. 開發人員發佈代碼到Git倉庫
  2. Jenkins同步代碼到本地，並使用前端構建工具（如：Grunt等）生成構建產物
  3. 將構建產物統一備份到相應目錄，作好發佈產物的備份，方便回滾
  4. 部署測試服務器
  5. 測試……
  6. 發佈……

7.4   移動端App項目

主要表明有：Android等。

過程以下：

  1. 開發人員發佈代碼到Git倉庫

  2. Jenkins同步代碼到本地，並使用構建工具生成構建產物Apk

  3. 將構建產物統一備份到相應目錄，作好發佈產物的備份，方便回滾

  4. 安裝到設備，執行測試

  5. 測試
    • 若是測試經過，發佈到各大應用市場
    • 若是測試未經過，發現bug後駁回

8   運行效果

Jenkins系統運行界面：

Jenkins自己能夠實現以下功能：

  • 完成項目持續集成及持續發佈
  • 對構建過程進行記錄
  • 構建完畢後能夠發郵件或者微信通知相應的人員，造成良好的反饋機制

再經過文章前半部分提到的系統，團隊就能夠達到 持續交付 和 持續部署 的目的，從而實現項目的 快速迭代 。

持續交付：

持續部署：

固然，還有後續的更多的擴展功能，就須要測試開發人員去實現了。

9   小結

此文做爲 持續集成 系列文章的具體技術實現部分，介紹了一個通用的技術框架的解決方案。剩下的就是各類針對本身的工程特性是編寫各類腳本和安裝各類環境了。這樣 理論加實踐，就構成了可以提供生產力的 持續集成 系統，你們Enjoy it吧。

目前以 Google 爲表明的大型的互聯網公司，基本上都是保持着這樣的開發節奏。《Google軟件測試之道》裏面提到了這樣的生產方式，可是沒有給出具體的技術解決方案，本文則將這種構想進行技術落地，併發布此方案，但願可以給後來者一些幫助吧。

（若是你們有興趣，後面能夠針對某個具體的項目，來一個完整的持續集成示例，包括構建代碼的編寫，及過程的截圖等等。可是若是反響不大，就再也不浪費時間了）

http://www.cnblogs.com/beer/p/5196438.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程