跳到主要內容
wen aidev

現代軟體測試與 AI 實戰 (8):Quality Policies 實踐,在 CI/CD 打造品質防線

5 分鐘po-wen

有了優秀的單元與整合測試後,我們必須將其轉化為 Quality Policies(品質政策)。本篇展示如何在 GitHub Actions 實作 Quality Gate,打造堅不可摧的 CI/CD 流程。

目錄

系列文章地圖

點節點可以直接跳到那一篇。

在上篇Built-in Quality 與測試重用中,我們確立了 DevOps 與 Lean 原則,將測試工作左移。

但光靠團隊文化與口頭約定是不夠的。「只要是人,就會犯錯,或者想偷懶。」這時候我們就需要將品質要求具象化,轉變成機器的守門員。這就是 Quality Policies(品質政策) 的精神所在。


什麼是 Quality Policies 作為 Enabler?

在傳統軟體開發流程中,品質政策往往是一份厚厚的 Word 文件,要求工程師「請確保覆蓋率大於 80%」、「請注意命名規範」、「發 PR 前請務必跑過一次測試」。 但真實情況是,在死線(Deadlines)的壓迫下,Code Review 很容易流於形式。

將 Quality Policies 提升為 Enabler(驅動者),在於我們引進了「Policy as Code」的概念。 我們把原本死板的文件要求,寫成了 CI/CD 工具(如 GitLab CI、GitHub Actions)裡的腳本。只要不符合規範(例如測試壞了、覆蓋率掉了、有 Linter 錯誤),系統就直接擋下(Block)你的 Pull Request。

Quality Gate(品質閘門)就是寫在 CI/CD 腳本裡的品質規範,PR 沒通過 Lint 或測試,系統就擋下合併。

CI/CD · Quality gate
1
開 PR
有人對 main 開了 Pull Request,pull_request 事件觸發 PR Quality Gate workflow。
2
Gate 1 Lint
yarn lint 先檢查語法與命名規範,這次通過。
3
Gate 2 測試
yarn test --coverage 跑單元與整合測試,有一個測試壞了,quality-checks 變成紅叉。
4
擋下合併
分支保護把 quality-checks 列為必要檢查,紅叉沒消失前,Merge 按不下去。
5
修好再推
修好測試再 push,workflow 重跑一次,兩道 Gate 都通過才允許合併。
跑完的檢查 0擋下合併 0合併進 main 0
PULL REQUEST
PR → main
on: pull_request
workflow 已啟動
PR QUALITY GATE(GITHUB ACTIONS)
Gate 1 · Linting 檢查等待
$ yarn lint
Gate 2 · 測試與覆蓋率等待
$ yarn test --coverage
BRANCH PROTECTION
必要檢查(Required status check)
quality-checks等待
MERGE 到 MAIN
等檢查結果
紅叉消失前,誰都按不下 Merge
開 PR 就自動啟動

透過強制自動化的品質防線(Quality Gates),資深工程師(Reviewer)就能將寶貴的精力放在審查商業邏輯與架構,不必再挑剔排版、追問有沒有跑測試。


實戰 Demo:在 GitHub Actions 設定 Quality Gate

讓我們來看看如何具體在 GitHub Actions 中,實作一個包含 Linting、Test 以及 Coverage 的品質閘門。

🚧 範例:PR 檢查 Workflow (.github/workflows/pr-quality-gate.yml)

只要有人開了 Pull Request,這段自動化腳本就會啟動:

name: PR Quality Gate

on:
  pull_request:
    branches: ['main', 'develop']

jobs:
  quality-checks:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v6

      - name: Setup Node.js
        uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'yarn'

      - name: Install Dependencies
        run: yarn install --frozen-lockfile

      - name: 🛡️ Gate 1 - Linting 檢查
        run: yarn lint

      # 覆蓋率要能擋 PR,需在 Jest 設定 coverageThreshold;沒設門檻時 --coverage 只產出報告
      - name: 🛡️ Gate 2 - 單元 & 整合測試與覆蓋率
        run: yarn test --coverage

      # (可選) 🛠 Gate 3 - 搭配 SonarQube Cloud 進行深度靜態弱點掃描
      # - name: SonarQube Cloud Scan
      #   uses: SonarSource/sonarqube-scan-action@v8
      #   env:
      #     SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

GitHub Settings 設定分支保護 (Branch Protection)

單純有 CI Workflow 是不夠的。開發者仍然有可能無視紅色叉叉直接按「Merge」。 我們必須進入 Repository 的 Settings > Branches 中,新增一條規則:

  • 勾選 "Require status checks to pass before merging"
  • 將我們剛剛寫的 quality-checks 工作加入必要的檢查清單(Status Checks)之中。

現在,這條「Quality Policy」已經具象化並且無法妥協。

結論

此篇文章為《現代軟體測試與 AI 實戰》系列的架構與觀念分支畫下了句點。

我們從反模式冰淇淋筒出發,打破敏捷中的 Silos 隔離,導入了 Built-In Quality,最後透過 CI/CD 的 Quality Gates 將這些理念化作無情而高效的防護網。

接下來,如果你想了解這套防護網該如何運用最新的 AI Agent 技術來加強與自動化,請務必閱讀我們的 AI 輔助實作分支總結。

支持作者 ☕

台灣用戶:

透過 LINE Pay 支持

國際用戶:

透過 Ko-fi 支持

相關文章

留言討論

Facebook 留言