現代軟體測試與 AI 實戰 (8)：Quality Policies 實踐，在 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 Gates），資深工程師 (Reviewer) 就能將寶貴的精力放在審查商業邏輯與架構，而不是挑惕排版與追問有沒有跑測試。

實戰 Demo：在 GitHub Actions 設定 Quality Gate

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

name: PR Quality Gate

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

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

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

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

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

    - name: 🛡️ Gate 2 - 單元 & 整合測試與覆蓋率
      run: yarn test --coverage

    # (可選) 🛠 Gate 3 - 搭配 SonarCloud 進行深度靜態弱點掃描
    # - name: SonarCloud Scan
    #   uses: SonarSource/sonarcloud-github-action@master
    #   env:
    #     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    #     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 輔助實作分支總結。