雲手機GitLab CI集成：自動化測試與持續部署實戰指南

為什麼需要雲手機與GitLab CI的聯姻？

在跨境電商、社群媒體行銷和遊戲搬磚的日常運營中，你很可能遇到過這些痛點：每次應用更新都要手動在幾十臺手機上重新安裝、測試；多帳號運營時頻繁觸發平臺風控，因為裝置指紋被封鎖；想利用CI/CD流程自動跑迴歸測試，卻發現實體手機管理難、成本高。

傳統的CI/CD結合物理裝置或模擬器，要麼硬體成本高昂（幾十臺手機堆滿辦公桌），要麼指紋作弊被平臺秒拒。而雲手機的出現，恰好填補了「可控、可程式設計、真實裝置模擬」的空白。將雲手機與GitLab CI整合後，你只需在程式碼倉庫推送一個新版本，CI管道就能自動分發到多臺雲手機執行安裝、截圖、UI測試，甚至完成社群媒體帳號的批量發文驗證，全程無需人工介入。

有數據顯示，採用雲手機+CI/CD的方案後，測試週期從4小時縮短至25分鐘，人力成本降低70%。今天這篇文章，我就手把手教你如何把蜂巢雲盒的雲手機接入GitLab CI，實現從程式碼到端到端自動化的飛躍。

GitLab CI基礎：你只需要一個Runner

GitLab CI的核心是Runner，它負責執行.gitlab-ci.yml中定義的作業。一個Runner可以運行在物理機、虛擬機器，也可以運行在雲手機所在的伺服器上。

為了和雲手機通訊，我們需要在Runner所在的機器上安裝ADB（Android Debug Bridge）。因為大多數雲手機底層都是Android系統，ADB是連接手機的唯一渠道。假設你已經有一個GitLab實例（或使用gitlab.com），接下來只需要：

註冊一個Runner：在專案Settings → CI/CD → Runners中取得token，在伺服器上執行 gitlab-runner register。
安裝ADB：adb devices 能列出所有連接的裝置。

但這裡有個關鍵：Runner本身不運行在雲手機上，而是運行在一臺有網路可達的Linux伺服器上，透過ADB連接雲手機。雲手機需要開啟ADB偵錯，並獲得一個固定的IP:埠。大部分雲手機服務商都會提供ADB連接地址，比如蜂巢雲盒就會在控制檯展示每臺裝置的ADB資訊。

實戰：編寫.gitlab-ci.yml實現自動化測試

假設你的專案是一個Android APK，每次提交後要在10臺雲手機上執行冒煙測試。我們需要一個script階段來安裝APK，並執行Monkey測試。

stages:
  - install
  - test

variables:
  APK_PATH: "app/build/outputs/apk/debug/app-debug.apk"
  DEVICES: "10.0.0.1:5555 10.0.0.2:5555 10.0.0.3:5555" # 示例地址

install:
  stage: install
  script:
    - for device in $DEVICES; do
        echo "Installing to $device";
        adb -s $device install -r $APK_PATH;
      done

test:
  stage: test
  script:
    - for device in $DEVICES; do
        echo "Running test on $device";
        adb -s $device shell monkey -p com.example.myapp --throttle 500 --randomize-script 1000;
        # 自訂指令碼截圖或logcat抓取
        adb -s $device exec-out screencap -p > screenshot_${device//./_}.png;
      done
  artifacts:
    paths:
      - "*.png"

當CI運行後，10臺雲手機同時安裝並執行Monkey測試，截圖自動上傳到GitLab。你甚至可以在測試失敗時自動重新分配裝置。

這裡要注意：雲手機如果頻繁重置，每次ADB連接地址可能會變。選擇像蜂巢雲盒這樣提供固定ADB連接地址和持續運行的服務就很重要。它的雲手機建立後IP和埠長期不變，7×24小時不關機，Runner可以直接寫死在配置裡，無需每次動態拉取裝置列表。

進階：獨立硬體指紋防關聯與多開管理

如果你的業務涉及多帳號運營（比如跨境電商同時管理50個社群媒體帳號、遊戲工作室同時跑10個角色），最大的敵人是平臺的反關聯檢測。傳統的雲手機如果共用硬體資訊（比如IMEI、MAC地址、裝置型號），很容易被識別為同一使用者。

蜂巢雲盒的核心賣點之一是獨立硬體指紋。每臺雲手機出廠時都分配了獨一無二的IMEI、Android ID、WLAN MAC等12項參數，並且這些參數在生命週期內不會變化，也不會被其他裝置共享。這一點在GitLab CI整合中非常關鍵：因為CI指令碼通常會安裝同一個APK，如果平臺檢測到幾十臺裝置擁有相同指紋，會立即封號。而蜂巢雲盒的獨立指紋讓每個測試帳號都像是真實的獨立使用者。

另外，GitLab CI的Pipeline可能同時觸發多個作業，你需要能同時連接多臺雲手機。蜂巢雲盒支援無限多開，你可以透過API批量建立、刪除、重置裝置，並在CI指令碼中動態管理裝置池。例如，在before_script中呼叫蜂巢雲盒的REST API分配一個空閒裝置：

RESPONSE=$(curl -s "https://api.nestbox.top/v1/device/allocate?pool=test-pool")
DEVICE_IP=$(echo $RESPONSE | jq -r '.ip')
echo "Allocated device: $DEVICE_IP"
adb connect $DEVICE_IP

這種方式避免了手動配置裝置列表，CI可彈性伸縮。而蜂巢雲盒的按分鐘計費模式，也讓你只為實際使用的裝置時間付費，測試結束後裝置自動釋放，成本降到最低——有使用者反饋，原本每月租50臺實體手機要花1.5萬元，切換到蜂巢雲盒後，每天只在CI執行時使用2小時，月費僅300元，降幅達98%。

實際場景：電商、社媒、遊戲各自怎麼用？

跨境電商：批量產品上架測試

假設你運營一個Shopee店鋪群，每天上架500個產品。每個產品需要手機拍攝、上傳、編輯。使用GitLab CI + 雲手機，你可以寫一個自動指令碼，從CSV讀取產品資料，在雲手機上模擬手動操作（透過ADB輸入、滑動），同時呼叫蜂巢雲盒的RPA自動化功能，實現無人值守上架。CI管道每週自動執行一次，50臺雲手機同時幹活，2小時搞定過去一週的工作量。

社群媒體行銷：多帳號定時發布

做TikTok或Instagram行銷的使用者，最怕頻繁切換帳號導致IP關聯。透過GitLab CI的定時任務（Schedule Pipeline），每天固定時間觸發，在每臺雲手機上打開對應App，自動發布預設內容。因為蜂巢雲盒的IP是純淨住宅IP，且每臺裝置硬體指紋獨立，平臺基本封號率降低90%以上。有團隊測試過，連續運行30天無封號記錄。

遊戲搬磚：批量掛機與自動化任務

對於放置類手遊（如《劍與遠征》），你需要24小時線上自動完成副本。GitLab CI不善於長期運行，但你可以結合Redis佇列：CI負責把任務指令推送給每臺雲手機，手機端運行一個常駐的Python指令碼（透過ADB保持連接）。蜂巢雲盒的99.95%可用性意味著即便遇到阿里雲故障，裝置也會自動遷移，確保你的搬磚號不會因為手機掉線而損失收益。實際案例：一家工作室使用100臺蜂巢雲盒跑《魔獸世界》懷舊服指令碼，每週產值穩定在5萬金幣，折合人民幣約6000元，裝置成本僅400元。

總結：為什麼選擇蜂巢雲盒？

從上面的實戰可以看出，雲手機和GitLab CI結合的關鍵在於：裝置必須穩定、可程式設計、指紋隔離、成本可控。

7×24運行：CI指令碼隨時可以連接，不用等手機開機；裝置永不掉線。
獨立硬體指紋：徹底杜絕多帳號關聯，通過率100%。
無限多開：沒有裝置數量上限，API管理友好。
RPA自動化：配合ADB或UiAutomator，實現全流程無人值守。
按分鐘計費：測試場景下，用多久付多久，不浪費一分錢。
99.95%可用性：阿里雲+高可用架構，全年宕機時間不超過4小時。

如果你的團隊正在為自動化測試、多帳號運營發愁，不妨嘗試把蜂巢雲盒整合進你的GitLab CI流程。從配置一個Runner開始，到幾百臺雲手機並行跑任務，只要一天就能上線。真正的效率提升，從來不是靠堆人力，而是用對的工具把重複工作交給程式碼。