基於Docker的可持續交付問題

Posted on by

在測試的立場上，希望開發編寫的代碼都是經過開發的單元測試的，但是事實上，這中間總是存在理想和現實的差距，既然如此，我們何不來開發部署環境後，對服務進行自動化測試驗證瞭。整體的設計思路就是開發編寫的代碼，使用Dockerfile構建成鏡像文件，然後使用docker-compose自動化啟動鏡像文件，下一步其實就很簡單瞭，我們測試這邊進行智能化的自動驗證，其實在前面的文章體系中，介紹中智能化測試完成後，在測試結束的時候出具體的測試報告以及如果存在問題，觸發整體報警的機制。本文章系列中主要結合CI持續集成的工具，把這個過程完全的自動化，以及智能化的過程。當然，使用的技術棧主要是Spring Boot。

創建Spring Boot的項目後，這地方簡單的寫一個測試的接口，controller層源代碼具體如下：

package com.example.app;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class AppController
{
   @RequestMapping("/index")
   public String hello()
   {
      return "Hello SpringBoot!";
   }
   @RequestMapping("/testDev")
   public  String testDev()
   {
      return "測試開發工程師";
   }
}

這部分的代碼其實相對而言是非常簡單的，這裡就不做詳細的解釋瞭。編寫代碼完成後，下來編寫Dockerfile的文件來構建鏡像，Dockerfile在項目中存放的位置主要是在src/main下的docker文件夾，創建docker文件夾後，在裡面創建Dockerfile的文件，然後在裡面包編寫需要構建鏡像的內容信息，具體目錄結構如下所示:

Dockerfile文件夾的內容具體為：

FROM java:8
MAINTAINER 樂卻思蜀
VOLUME /tmp
RUN mkdir /app
COPY app-0.0.1-SNAPSHOT.jar /app/app.jar
WORKDIR /app
EXPOSE 8081
CMD  ["java","-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]

下來在docker的文件夾創建docker-compose.yml文件，在該文件主要定義鏡像的資源，網絡以及啟動停止的過程，該文件的內容信息具體如下:

version: '3.2'
services:
  app:
    image: app:0.0.1-SNAPSHOT
    hostname: localhost
    ports:
    - "8081:8081"
    networks:
      - mynetwork
networks:
  mynetwork:
    external: true

在如上的文件中可以看到自定義瞭網絡是mynetwork，在docker中可以創建網絡，以及查看目前已有的網絡信息，具體如下：

docker network ls
NETWORK ID           NAME              DRIVER              SCOPE
5e0d06b35341         bridge            bridge              local
34f731bed1dc         host              host                local
4b5926f1e44d         mynetwork         bridge              local

下來編寫測試的代碼，測試的代碼這裡使用Python語言結合Pytest測試框架來編寫，具體測試模塊test_sprintboot.py的源碼如下：

import requests
import pytest 
def test_springboot_index():
  r=requests.get("http://localhost:8081/index")
  assert r.status_code==200
def test_springboot_testDev():
  r=requests.get("http://localhost:8081/testDev")
  assert r.status_code == 200

這個測試代碼相對而言是比較簡單的，這裡主要需要驗證的是服務自動化部署後智能化的驗證。

在如上的準備工作做好，下來在Jenkins中創建Pipeline的項目，Pipeline script的腳本具體如下：

pipeline{
    agent any
    stages{
        stage('build the image'){
            steps{
                sh '''cd /Applications/code/workSpace/data/app
                mvn clean package  -Dmaven.test.skip=true   docker:build'''
            }
        }
        stage('run the container'){
            steps{
                sh '''cd /Applications/code/workSpace/data/app/src/main/docker
                docker-compose up -d '''
            }
        }
        stage('smoke test'){
            steps{
                sh '''cd /Applications/code/workSpace/data/app/src/main/docker
                sleep 10s
                python3 -m pytest -v test_springboot.py'''
            }
        }
    }
}

下來開始在CI中構建和執行過程，構建後可視化的界面信息如下所示：

輸出的詳細信息在這裡隻顯示部分，具體如下：

======================== 2 passed, 3 warnings in 0.72s =========================
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

對於質量交付團隊而言，需要思考的點是，我們怎麼樣結合現有的技術來達成我們的目標和質量驗證的手段。其實一種驗證的研發體系流程是開發無論如何需要對自己編寫的代碼進行單元測試，這樣其實一個體系它是通過，整體體系我們完全可以持續流水線的方式來進行驗證，從而提高交付的效率以及提交給測試團隊是高質量的代碼。其實如上的思路很簡單，就是從Docker構建鏡像，到啟動容器，以及我們進行冒煙測試驗證，當然後續還有很多的流程，比如測試團隊其他的驗證手段，比如代碼質量審計，API等驗證。感謝您的閱讀和關註，後續會持續進行更新。

到此這篇關於基於Docker的可持續交付的文章就介紹到這瞭,更多相關Docker可持續交付內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：