前言
你有沒有遇過這種情況：
- 加班太累打錯字，結果上線才發現
- 需求變更，改了 A 功能結果 B 功能壞了
- AI 幫你寫的 code 看起來沒問題，跑起來才爆炸
這些問題的共通點是－－－－－－程式碼在上線前沒有被自動化地驗證過。
這就是 CI 要解決的事。
CI 是什麼？
CI（Continuous Integration，持續整合）的核心概念很簡單：
每次有人提交程式碼，就自動跑一次測試，確認沒有東西壞掉。
不是等到要上線才測，而是每一次 push、每一個 PR 都測。
這樣的好處是：
- 問題在合併前就被發現，不會炸到主線
- 看 PR 的人可以直接看到測試有沒有過，更有信心按下 Merge
- 長期下來，整個團隊對程式碼品質更有底氣
有些團隊甚至會在 CI 裡加上程式碼風格檢查，確保每個人寫出來的 code 長得一樣。
（至於單元測試本身怎麼寫，那是另一個大題目，這篇先聚焦在 CI 流程。）
那 CI 要怎麼做？
知道了 CI 的概念後，下一個問題是：實際上要用什麼工具來跑？
市面上有不少選擇，像是 Gitlab CI、CircleCI、Travis CI 等等。但如果你的程式碼已經放在 GitHub 上。
最簡單的方式就是用 GitHub 內建的工具－－－－－－GitHub Actions。
GitHub Actions 是什麼？
GitHub Actions 是 GitHub 內建的 CI/CD 工具。你不需要額外架設服務，只要在專案裡放一個 .yml 檔案，GitHub 就會幫你自動執行。
免費方案對公開 repo 完全免費，私有 repo 每月也有 2000 分鐘的額度，個人專案絕對夠用。
四個核心概念
在開始之前，先認識四個關鍵詞：
1. Event（事件）
觸發 workflow 的條件。最常見的就是：
push— 程式碼推上去時pull_request— 有人開 PR 時
還有很多其他事件，但這兩個就能涵蓋大部分日常情境。
2. Job（任務）
一組要執行的步驟。Job 之間預設是平行執行的，就像煮飯時可以一邊切菜一邊燒水。
但如果有先後關係，也可以設定依賴。就像煮泡麵－－－－－－水沒滾你就放麵，只會得到一坨碳水化合物。
3. Action（動作）
別人寫好的自動化工具，直接拿來用。例如 actions/checkout 會幫你把程式碼下載到執行環境，shivammathur/setup-php 會幫你裝好 PHP。
不用自己從頭寫安裝腳本，一行 uses 搞定。
4. Runner（執行器）
實際跑你 Job 的虛擬機器。GitHub 提供 Ubuntu、Windows、macOS 三種，大部分情況用 ubuntu-latest 就好。
實際範例：push 後自動跑測試
以下是一個 PHP（Laravel）專案的 workflow 範例。在專案根目錄建立 .github/workflows/ci.yml：
# Workflow 的名稱，會顯示在 GitHub Actions 頁面
name: CI
# 觸發條件
on:
push:
branches:["main"]
pull_request:
branches:["main"]
# 任務清單
jobs:
build:
# 執行環境
runs-on: ubuntu-latest
# 步驟（按順序執行）
steps:
# 下載專案源碼到 Runner
-uses: actions/checkout@v4
# 設定 PHP 環境
-name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version:"8.1"
extensions: mbstring, xml, pdo_sqlite, curl
coverage: none
# 安裝依賴套件
-name: Install dependencies
run: composer install --prefer-dist --no-interaction
# 準備環境設定
-name: Copy .env
run: cp .env.example .env
# 產生 Laravel 金鑰
-name: Generate APP_KEY
run: php artisan key:generate
# 執行測試（用記憶體內的 SQLite，不需要額外裝資料庫）
-name: Run tests
env:
DB_CONNECTION: sqlite
DB_DATABASE:":memory:"
run: php artisan test
這個範例是 Laravel 專案，但概念是通用的。換成 Node.js 就是把
setup-php換成setup-node，composer install換成npm install，php artisan test換成npm test。
執行後會看到什麼？
成功的情況
當你 push 程式碼後，到 GitHub repo 頁面點 Actions 分頁，會看到你的 workflow 正在執行。
全部通過的話，commit 旁邊會出現一個綠色勾勾。點進去可以看到每個步驟的執行 log。
如果是 PR，底部的 checks 區塊會顯示綠色的 All checks have passed，看 PR 的人最喜歡看到綠燈了。
失敗的情況
如果有測試沒過，commit 旁邊會變成紅色叉叉。
點進去 Actions 可以看到是哪個步驟失敗、錯誤訊息是什麼。通常直接看 Run tests 那個步驟的 log 就能找到問題，接下來就是開心的debug 時間啦，恭喜你加班。
PR 底部也會顯示紅色的 Some checks were not successful，提醒你修好再合併。
跟 PR 的關係
CI 最常見的用法就是搭配 PR：
- 你開一個 PR
- GitHub Actions 自動跑測試
- 測試全過 → 綠色勾勾 → Reviewer 安心 merge
- 測試沒過 → 紅色叉叉 → 你修好再 push，CI 會再跑一次
現在就動手試試
- 使用我的Github Repo（或者你也可以自己建一個）
- 依照 README指引完成步驟
- 到 Repo 的 Actions 頁面，看它跑起來
第一次看到綠色勾勾出現的時候，你就懂 CI 的價值了。
總結
CI 不是什麼高深的東西，本質就是：自動化該做的事（我自己偶爾也會忘記在本地跑測試就推上去）。
GitHub Actions 讓這件事的門檻非常低。
花 30 分鐘設定一次，之後每次 push 都能自動幫你驗證程式碼，省下的時間和避免的災難絕對值回票價。
