去年隨(sui)著 3.1.1.0 版(ban)本的(de)發布，TDengine 數據接(jie)入(ru)工具(ju) taosX 正式(shi)推出。該(gai)工具(ju)具(ju)備(bei)強(qiang)大的(de)數據抓取、清(qing)洗(xi)、轉換及加載（ETL）功能(neng)。它(ta)不僅(jin)能(neng)無縫對接(jie)物聯網中的(de) MQTT 協議(yi)，更(geng)重(zhong)要的(de)是能(neng)夠(gou)連接(jie)到(dao)工業數據源如(ru) OPC-UA、OPC-DA、PI System 等(deng)。借助(zhu)這(zhe)一(yi)模塊，工業場景中常用的(de) SCADA、DCS 等(deng)系統(tong)無需編寫任何代碼，僅(jin)需通過簡單配(pei)置即可實(shi)現數據的(de)實(shi)時、持續導入(ru)至 TDengine。

此外，該工(gong)具支持在(zai) BI 和可視(shi)化工(gong)具中展示數據，實(shi)(shi)現遠程監控、實(shi)(shi)時報(bao)警和可預測性維護等功能(neng)。用(yong)戶(hu)還可以通(tong)過(guo)微信小程序直接查看設備(bei)的(de)運行狀(zhuang)態(tai)和生成報(bao)表。因此，taosX 不僅提升了企業的(de)操作效率，還大幅簡(jian)化了數據管理(li)流程，助(zhu)力企業更(geng)專注于核心(xin)業務的(de)創新(xin)與發展，自(zi)推出以來，便(bian)獲得了眾多企業客戶(hu)的(de)關注。

在(zai)本(ben)篇文章中(zhong)，我們(men)將深入探討 taosX 在(zai)持續集成（CI）流程優化(hua)(hua)以及(ji)其具(ju)體應用場景中(zhong)的實踐。在(zai)本(ben)次 CI 流程優化(hua)(hua)后，taosX 的工程質量得到了大幅(fu)提(ti)升(sheng)，助(zhu)力(li)企業能(neng)夠更有效地利用其數據資源。

使用 GitHub Action 優化現有 CI 流程

在優化之前，taosX 的(de) CI 流程是(shi)基于 Jenkins 構建的(de)。具(ju)(ju)體來說，當 taosX/Explorer 的(de) main/3.0 分支有代(dai)碼合并(bing)時(shi)，通過在 GitHub 倉(cang)庫中配(pei)置(zhi)的(de) webhook 自動(dong)(dong)觸發編譯和(he)部署的(de) Jenkins 作業(ye)。該作業(ye)完(wan)成(cheng)后，根據 Jenkins 作業(ye)之間配(pei)置(zhi)的(de)依賴關系(xi)，可(ke)以自動(dong)(dong)或手動(dong)(dong)觸發自動(dong)(dong)化測試(shi)用例的(de)執行(xing)作業(ye)。測試(shi)用例是(shi)通過 pytest 工具(ju)(ju)驅動(dong)(dong)的(de)，執行(xing)完(wan)畢后會生成(cheng) Allure 測試(shi)報(bao)告。這(zhe)一流程確保(bao)了(le)代(dai)碼變更的(de)連(lian)續集成(cheng)和(he)質量控制。

為解決 CI 流程觸發滯后性等問題，TDengine 研發團隊決定(ding)采用 Github 提供的 CI/CD 解決方案 對 taosX 的 CI 流程進(jin)行優化。

在(zai)使(shi)用(yong)(yong) Github Action 需要(yao)確定 workflow 中(zhong)任(ren)務執(zhi)行所使(shi)用(yong)(yong)的(de) runner。所謂 runner 就是(shi)可(ke)以運行 Github Action 中(zhong)的(de)任(ren)務的(de)機器(qi)(qi)(qi)。在(zai) runner 中(zhong)可(ke)以執(zhi)行倉庫 clone，軟件的(de)安裝(zhuang)等任(ren)務。Github 默(mo)認提供(gong)了 runner 來執(zhi)行 Action 中(zhong)的(de)任(ren)務，這些 runner 其(qi)實是(shi) Github 安裝(zhuang)好(hao)的(de)虛擬機，這些 runner 也(ye)被(bei)稱(cheng)(cheng)為(wei) 。有 Github 提供(gong)的(de)機器(qi)(qi)(qi)，相對(dui)的(de)也(ye)可(ke)以用(yong)(yong)用(yong)(yong)戶自己的(de)機器(qi)(qi)(qi)來運行 workflow。這些機器(qi)(qi)(qi)作為(wei) runner 時(shi)被(bei)稱(cheng)(cheng)為(wei) 。在(zai)使(shi)用(yong)(yong) Github-hosted runner 的(de)時(shi)候無法自定義硬(ying)件資源（比如(ru) cpu 核(he)數，內(nei)存等）。而 Self-hosted runner 則可(ke)以控制硬(ying)件資源，操作系統以及安裝(zhuang)的(de)各(ge)個(ge)軟件。

在(zai) taosx 運(yun)行(xing)的(de)(de)(de)過程(cheng)中(zhong)由于需(xu)要加快 CI 流(liu)程(cheng)的(de)(de)(de)運(yun)行(xing)，需(xu)要一(yi)個(ge)(ge)硬件(jian)配置較高的(de)(de)(de)設備（taosx 在(zai)編(bian)譯(yi)的(de)(de)(de)時候(hou)(hou)耗(hao)時較長，實際測試(shi)中(zhong)發現如果使用(yong)(yong) 2c4g 的(de)(de)(de)虛擬機進行(xing)編(bian)譯(yi)的(de)(de)(de)話耗(hao)時在(zai) 20 分(fen)鐘左右，而使用(yong)(yong) 40c256g 的(de)(de)(de)物理機編(bian)譯(yi)時，耗(hao)時在(zai) 3 分(fen)鐘左右）。在(zai)執(zhi)行(xing)端到端測試(shi)的(de)(de)(de)時候(hou)(hou)可以提前將測試(shi)代碼 clone 到一(yi)個(ge)(ge)固定位置，每次(ci)只需(xu)要 git pull 進行(xing)更新(xin)，這樣(yang)也會節省代碼拉取的(de)(de)(de)時間。鑒于以上因素，在(zai)執(zhi)行(xing) taosx CI 的(de)(de)(de)是時候(hou)(hou)選用(yong)(yong)了 Self-hosted runner。

注意：Self-hosted runner 并不(bu)局限在物理機(ji)(ji)或虛擬機(ji)(ji)上，可(ke)以是一個容器，也可(ke)以部(bu)署到云端(duan)。

Github-hosted runner 與(yu) Self-hosted runner 的詳細區(qu)別見 。

在(zai)確定使用 Self-hosted runner 之后，就需要對現有的(de)流程所使用的(de) workflow 文件進行編排，taosX CI 完整(zheng)的(de) workflow 主(zhu)要包含以下環節(jie)：

此流程是通過編寫 YAML 格式的 workflow 文件來定義的，該文件需要放在 taosX 代碼倉庫的.github/workflows目(mu)錄下。其定義(yi)分為(wei)以下幾個部分：

# 名稱
name: PR-QA-workflow

# 觸發方式
on:
  workflow_dispatch:
  pull_request:

# 全局變量
env:
  RELEASE_HOST: 192.168.1.45
  RUSTFLAGS: "-C instrument-coverage --cfg tokio_unstable"
  ARTIFACT_BASE_DIR: /data/artifacts
  COVERAGE_BASE_DIR: /data/coverage
  DIR_PATH: ${{ github.event.number }}
  RUN_UNIT_TEST_FILE_FLAG: /etc/taos/taosx_run_unit_test

# 具體的job
jobs:
  build_rust:
    ...
  build_go:
    ...

下文(wen)將(jiang)按照(zhao) workflow 的順(shun)序，對每個環(huan)節進行逐一介(jie)紹。

觸發

用于觸發 workflow 的配(pei)置如下：

on:
  workflow_dispatch:
  pull_request:

說明：

• on.workflow_dispatch：表示該 workflow 可以手動觸發，不過 GitHub 限制該 workflow 必須位于默認分支上才可以手動觸發，并且也只會在默認分支上生效。
• on.pull_request：表示當提交 PR 的時候對當前分支（PR 的源分支）觸發。

關于觸(chu)發事件(jian)的(de)完整描述可參考：

全局環境變量

在 workflow 中(zhong)，我們(men)設置了一些全(quan)局的環境變量，以供 workflow 中(zhong)的 job 使用，具(ju)體(ti)如下所示(shi)：

env:
  RELEASE_HOST: 192.168.1.45
  RUSTFLAGS: "-C instrument-coverage --cfg tokio_unstable" # rust 用于獲取覆蓋率的編譯用環境變量
  ARTIFACT_BASE_DIR: /data/artifacts # 編譯之后編譯中間文件及可執行文件存放的根目錄
  COVERAGE_BASE_DIR: /data/coverage # 生成報告后報告存放的根目錄
  DIR_PATH_3_0: "3.0" # 下一級使用 3.0 或 PR Number
  DIR_PATH: ${{ github.event.number }} # 下一級使用 3.0 或 PR Number
  RUN_UNIT_TEST_FILE_FLAG: /etc/taos/taosx_run_unit_test

編譯

在(zai)編(bian)譯(yi)(yi)過程中(zhong)，taosx、taosx-agent、opc 以(yi)及 mqtt 各(ge)個組件需要(yao)設置(zhi)特定的(de)環境(jing)變量，以(yi)便輸出插樁(zhuang)程序(xu)。由于這些組件在(zai)編(bian)譯(yi)(yi)過程中(zhong)沒有相(xiang)互依賴，因此設置(zhi)了(le)三個可以(yi)并行執行的(de)任務，分別負責各(ge)自組件的(de)編(bian)譯(yi)(yi)工作。

  build_rust:
    runs-on: [self-hosted, linux, x64, qa, rust]
    
  build_go:
    runs-on: [self-hosted, linux, x64, qa, go]
  
  build_java:
    runs-on: [self-hosted, linux, x64, qa, java]

三個編(bian)(bian)譯任務(wu)—Rust編(bian)(bian)譯、Go編(bian)(bian)譯、Java編(bian)(bian)譯—之間不存在依賴關系(xi)，且各自在不同(tong)的機(ji)器上運行。因此，這三個任務(wu)可以同(tong)時并行執行。

在 taosx 及(ji) taox-agent 編譯和單元(yuan)測試執行完(wan)成之(zhi)后，需要將編譯過(guo)程(cheng)中產(chan)生的(de)中間文件(jian)及(ji)可(ke)執行程(cheng)序拷貝至特定目(mu)錄(lu)，用以留(liu)存和區分。

  - name: Copy files
    run: |
      ls $ARTIFACT_BASE_DIR/$DIR_PATH/bin || mkdir -p $ARTIFACT_BASE_DIR/$DIR_PATH/bin
      cp ./target/debug/taosx-build/debug/taosx ./target/debug/taosx-agent-build/debug/taosx-agent $ARTIFACT_BASE_DIR/$DIR_PATH/bin/
      cp -r ./target/debug/taosx-profraw/ $ARTIFACT_BASE_DIR/$DIR_PATH/
      cp -r ./target/debug/taosx-agent-profraw/ $ARTIFACT_BASE_DIR/$DIR_PATH/
      cd ..
      tar --exclude=./taosx/target/* -zcvf taosx.tar.gz ./taosx
      cp taosx.tar.gz $ARTIFACT_BASE_DIR/$DIR_PATH/
      rm taosx.tar.gz
      tar -xzf $ARTIFACT_BASE_DIR/$DIR_PATH/taosx.tar.gz -C $ARTIFACT_BASE_DIR/$DIR_PATH/
      rm $ARTIFACT_BASE_DIR/$DIR_PATH/taosx.tar.gz

單元測試

目前(qian)運行(xing)了 taosx、opc、mqtt 三個(ge)組件的(de)(de)單元測(ce)試(shi)，單元測(ce)試(shi)的(de)(de)運行(xing)與編譯處于同一(yi)階(jie)段。

前期由(you)于單元測試可能(neng)存在(zai)(zai)不穩(wen)定，或者單元測試耗時較長等問題的存在(zai)(zai)，添加了依(yi)據 /etc/taos/taosx_run_unit_test 該文(wen)(wen)件是否存在(zai)(zai)執行單元測試的邏(luo)輯。若該文(wen)(wen)件存在(zai)(zai)，則執行。

taosX 編譯及(ji)運行單元測試的(de)配置如下：

- name: Build taosx
        run: |
          # build taosx and taosx-agent
          # export RUSTFLAGS="-C instrument-coverage --cfg tokio_unstable"
          rm -rf ./target/debug/taosx-profraw/
          export LLVM_PROFILE_FILE="./target/debug/taosx-profraw/taosx-%p-%m.profraw"
          cargo build --target-dir ./target/debug/taosx-build/
      - name: taosx unit test
        continue-on-error: true
        run: |
          if [ -f "$RUN_UNIT_TEST_FILE_FLAG" ]; then
              echo "run taosx unit test"
              cargo llvm-cov nextest --workspace
              cargo llvm-cov report --lcov --output-path $ARTIFACT_BASE_DIR/$DIR_PATH/taosx-unit-test-lcov.info
          fi

taosX 運行(xing)完單元測試之后(hou)，會(hui)輸出單元測試覆(fu)蓋率報告到 $ARTIFACT_BASE_DIR/$DIR_PATH/，用于(yu)之后(hou)與端到端測試的覆(fu)蓋率結果進行(xing)合并。

MQTT 編(bian)譯機(ji)運(yun)行單元測試(shi)的配置如(ru)下：

- name: Build mqtt
        run: |
          cd plugins/mqtt
          go build -cover -o taosx-mqtt

      - name: Run Mqtt Unit Test
        continue-on-error: true
        run: |
          cd plugins/mqtt
          if [ -f "$RUN_UNIT_TEST_FILE_FLAG" ]; then
            echo "run mqtt unit test"
            go test -coverpkg=./... -coverprofile=mqtt_unit_report.txt  -timeout=5s ./...
          fi
      - name: Copy MQTT Files
        run: |
          cd plugins/mqtt
          if [ -f "mqtt_unit_report.txt" ]; then
            ssh root@$RELEASE_HOST "ls $ARTIFACT_BASE_DIR/$DIR_PATH/go_cover/mqtt_cover_data/ || mkdir -p $ARTIFACT_BASE_DIR/$DIR_PATH/go_cover/mqtt_cover_data/"
            scp mqtt_unit_report.txt root@$RELEASE_HOST:$ARTIFACT_BASE_DIR/$DIR_PATH/go_cover/mqtt_cover_data/
            rm mqtt_unit_report.txt
          fi
          ssh root@$RELEASE_HOST "ls $ARTIFACT_BASE_DIR/$DIR_PATH/bin/mqtt || mkdir -p $ARTIFACT_BASE_DIR/$DIR_PATH/bin/mqtt/"
          scp taosx-mqtt root@$RELEASE_HOST:$ARTIFACT_BASE_DIR/$DIR_PATH/bin/mqtt/

同樣，MQTT 的單元測(ce)試(shi)(shi)報(bao)告(gao)在單元測(ce)試(shi)(shi)完(wan)成之后(hou)會輸出，并(bing)拷(kao)貝到 $ARTIFACT_BASE_DIR/$DIR_PATH/go_cover/mqtt_cover_data/，用于(yu)之后(hou)與端到端測(ce)試(shi)(shi)覆蓋率(lv)報(bao)告(gao)合并(bing)。

部署

在部署過程(cheng)中，需要進(jin)行(xing)兩次部署操(cao)作(zuo)。首先是(shi)為(wei) MQTT 用例的(de)執行(xing)進(jin)行(xing)部署。在這(zhe)一階(jie)段，由于 taosx 或 taosx-agent 需要以子進(jin)程(cheng)的(de)形(xing)式啟動 taosx-mqtt，因此在運行(xing) MQTT 用例時，必須配置相應的(de)環境變(bian)量。如下：

steps:
      - name: Deploy taosx
        run: |
          pwd
          ls ${{ github.workspace }}
          # run taosx
          ssh root@$RELEASE_HOST "ls $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/go_cover/mqtt_cover_data/ || mkdir -p $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/go_cover/mqtt_cover_data/"
          ssh root@$RELEASE_HOST "nohup sh -c 'DATABASE_URL=/var/lib/taos/taosx/taosx.db LLVM_PROFILE_FILE=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/taosx-profraw/taosx-%p-%m.profraw GOCOVERDIR=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/go_cover/mqtt_cover_data/ PLUGINS_HOME=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/ ENABLE_COVERAGE=true nohup $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/taosx serve > $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/taosx.log 2>&1 &'"

      - name: Deploy taosx-agent
        run: |
          pwd
          ls ${{ github.workspace }}
          # run taosx-agent
          ssh root@$RELEASE_HOST "nohup sh -c 'GOCOVERDIR=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/go_cover/mqtt_cover_data/ PLUGINS_HOME=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/ ENABLE_COVERAGE=true LLVM_PROFILE_FILE=$ARTIFACT_BASE_DIR/$DIR_PATH_3_0/taosx-agent-profraw/taosx-agent-%p-%m.profraw nohup $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/taosx-agent > $ARTIFACT_BASE_DIR/$DIR_PATH_3_0/bin/taosx-agent.log 2>&1 &'"

第(di)二(er)次(ci)(ci)部署與第(di)一次(ci)(ci)部署大體(ti)相同，區(qu)別是 GOCOVERDIR 的(de)賦值會修改為(wei) OPC 準備的(de)目(mu)錄(lu)。

GOCOVERDIR=$ARTIFACT_BASE_DIR/$DIR_PATH/go_cover/opc_cover_data

端到端測試

在部署(shu)完成之后，就可(ke)以執行端(duan)到(dao)端(duan)的(de)測試。由于第一次部署(shu)設置(zhi)的(de)是 MQTT 的(de)覆蓋率文(wen)件的(de)路徑，所以第一次運行的(de)測試也是 MQTT 的(de)用例。

端到端測試的代碼已經存放至 /data/github/TestNG_taosX，每(mei)次執行(xing)之前只需要使(shi)用 git pull 更新代(dai)碼即可。

在(zai)執(zhi)行完端(duan)到端(duan)測試(shi)之后應(ying)該停止 taosx 及(ji)(ji) taosx-agent 用于獲取 taosx 及(ji)(ji) agent 的覆(fu)蓋率信(xin)息。此時需要通(tong)過 kill -2 關閉，這樣能(neng)夠(gou)發(fa)送 SIGINT 信(xin)號給指定(ding)的進程，使得(de)進程能(neng)夠(gou)優雅退出(chu)，不能(neng)通(tong)過 kill -9 否則無法(fa)成(cheng)功獲取覆(fu)蓋率信(xin)息。

MQTT 的端(duan)到(dao)端(duan)測試用例的執行配置(zhi)如下：

test_mqtt:
    runs-on: [self-hosted, linux, x64, qa, rust]
    needs: deploy_for_mqtt
    steps:
      - name: Update Repo
        run: |
          # 這里最好是 TestNG_taosx 已經被拉取到一個固定的位置
          # 重新登錄執行 git pull，因為當前的 git 倉庫對應的是 taosx
          ssh root@$RELEASE_HOST "cd /data/github/TestNG_taosX && git pull"

      - name: Run Test
        run: |
          ls $COVERAGE_BASE_DIR/$DIR_PATH/allure_profile || mkdir -p $COVERAGE_BASE_DIR/$DIR_PATH/allure_profile
          cd /data/github/TestNG_taosX && source ./setenv.sh && poetry install && cd tests && poetry run pytest --alluredir=$COVERAGE_BASE_DIR/$DIR_PATH/allure_profile --timeout=300 -m sanity mqtt_test.py

      - name: Stop taosx-agent & taosx
        run: |
          pids=$(pgrep taosx-agent); if [ -n "$pids" ]; then for pid in $pids; do "run kill -9 taosx-agent"; kill -2 "$pid"; done; fi
          pids=$(pgrep taosx); if [ -n "$pids" ]; then for pid in $pids; do "run kill -9 taosx"; kill -2 "$pid"; done; fi

      - name: Force stop taosx-agent & taosx
        if: always()
        run: |
          pids=$(pgrep taosx-agent); if [ -n "$pids" ]; then for pid in $pids; do "run kill -9 taosx-agent"; kill -9 "$pid"; done; fi
          pids=$(pgrep taosx); if [ -n "$pids" ]; then for pid in $pids; do "run kill -9 taosx"; kill -9 "$pid"; done; fi

執行除 MQTT 之外的用例的 pytest 命令：

cd /data/github/TestNG_taosX && source ./setenv.sh && poetry install && cd tests \
&& poetry run pytest --alluredir=$COVERAGE_BASE_DIR/$DIR_PATH_3_0/allure_profile \
--timeout=300 -m sanity -k "not mqtt_test.py"

說明：

• 執行 poetry install 安裝測試依賴
• 執行 pytest 命令來運行自動化測試，通過-m 參數指定執行帶有 sanity 標簽的用例
• 通過 --alluredir 參數指定報告的目錄
• 通過 --timeout 指定每個用例的超時時間，避免出現用例長時間掛起的情況

生成覆蓋率報告

Job 的(de)日(ri)志截圖：

taosX 的覆蓋(gai)率報告截圖：

OpenTSDB 的(de)覆蓋率報告截圖：

OPC 的覆蓋率報告截圖：

問題介紹

這里(li)的測(ce)(ce)試報(bao)(bao)告則是 pytest 運(yun)行(xing)完(wan)成(cheng)之后，端到(dao)端測(ce)(ce)試的測(ce)(ce)試報(bao)(bao)告。測(ce)(ce)試報(bao)(bao)告生成(cheng)的邏輯如下：

- name: allure report
        run: |
          allure generate $COVERAGE_BASE_DIR/$DIR_PATH_3_0/allure_profile -o $COVERAGE_BASE_DIR/$DIR_PATH_3_0/allure_report/ --clean
          # 這里會直接輸出報告的地址
          echo "see report at $REPORT_BASE_URL/$DIR_PATH_3_0/allure_report/"

Job 的日志如(ru)下：

其(qi)中的測試報(bao)(bao)告鏈接(jie)可以直接(jie)點擊，測試報(bao)(bao)告如下圖(tu)所示：

一個完整的例子

1. 開發者通(tong)過提交 PR 觸發 CI 運行。

2. 通過點擊(ji)執(zhi)行(xing)的(de) Action 可(ke)以查看(kan)執(zhi)行(xing)的(de)結果。

開發者在查(cha)看(kan)該 Action 的(de)時候可以在底部看(kan)到(dao)流(liu)程中哪個 Job 的(de)運行是出錯了的(de)。

3. 可以通過點擊(ji)下方的出錯(cuo)的任務查看任務出錯(cuo)的原因。

4. 最后可以(yi)通(tong)過點擊 generate_report 中(zhong)查看報告的具體結果。

綜(zong)上所(suo)述，我(wo)們(men)已經實現了一(yi)項自動(dong)化功能：每當開(kai)發(fa)人(ren)員在(zai) taosX 倉庫提交 Pull Request（PR）時，即自動(dong)觸發(fa) CI 流(liu)程(cheng)。通(tong)過這(zhe)一(yi)流(liu)程(cheng)，開(kai)發(fa)和測試人(ren)員能夠利用(yong)生成的(de)測試報告和覆蓋(gai)率報告來評估 PR 中的(de)代碼(ma)變更(geng)。如果你(ni)也對(dui) taosX 這(zhe)一(yi)工具感興趣，歡迎添加小T微信(xin)（tdengine）與 TDengine 的(de)解決方案(an)專(zhuan)家進行(xing)一(yi)對(dui)一(yi)溝通(tong)。我(wo)們(men)將提供專(zhuan)業的(de)指導，幫助你(ni)更(geng)深入地了解和應用(yong) taosX。