เริ่มต้น CI ด้วย GitHub Actions: คู่มือลงมือทำจริงใน 6 ขั้นตอน

เริ่มต้น CI ด้วย GitHub Actions: คู่มือลงมือทำจริงใน 6 ขั้นตอน

ทีมที่รวมโค้ดกันบ่อยแต่ไม่มีระบบตรวจอัตโนมัติ จะเจอปัญหาเดิมซ้ำ ๆ คือโค้ดพังหลุดเข้า main และ "ที่เครื่องผมรันได้" บทความนี้พาคุณตั้ง Continuous Integration ตัวแรกด้วย GitHub Actions บน repo จริง ใช้เวลาประมาณ 10 นาที

สารบัญ

1. CI คืออะไร และแก้ปัญหาอะไร
2. GitHub Actions และศัพท์ที่ต้องรู้
3. ภาพรวม 6 ขั้นตอนที่จะทำ
4. ขั้นที่ 1–2 สร้าง branch และไฟล์ workflow
5. ขั้นที่ 3 เขียนไฟล์ ci.yml ฉบับเต็ม
6. ขั้นที่ 4–5 push เปิด PR และอ่านผลใน Actions
7. ขั้นที่ 6 ตั้ง required check แล้วทดสอบว่าบล็อกได้จริง
8. ปัญหาที่พบบ่อยและวิธีแก้
9. แนวปฏิบัติที่ดี
10. สรุป

สิ่งที่ต้องเตรียม

หมายเหตุ ถ้าโปรเจกต์ของคุณเป็น Python, Go หรือ Java แนวคิดทุกขั้นตอนเหมือนกันทั้งหมด เปลี่ยนเฉพาะ action ที่ใช้ติดตั้งภาษาและคำสั่งใน run: เท่านั้น

1. CI คืออะไร และแก้ปัญหาอะไร

Continuous Integration (CI) คือแนวทางที่นักพัฒนารวมโค้ดเข้าสู่ที่กลางบ่อย ๆ และทุกครั้งที่รวม จะมีระบบ build และ test อัตโนมัติทำงานทันที เพื่อจับปัญหาให้เร็วที่สุด

วงจรพื้นฐานมีสี่จังหวะ: push โค้ด → build อัตโนมัติ → รัน test → รายงานผล

เปรียบเทียบให้เห็นภาพ:

จุดที่ CI ทำงานใน GitHub Flow คือตอน เปิดหรืออัปเดต Pull Request — build/test ทุกครั้งก่อนโค้ดจะถูกรวมเข้า main จึงทำหน้าที่เป็น "ยาม" ที่คอยกันโค้ดเสีย

2. GitHub Actions และศัพท์ที่ต้องรู้

GitHub Actions คือระบบ CI/CD ที่มากับ GitHub ในตัว เราเขียน workflow เป็นไฟล์ YAML เก็บไว้ใน repo แล้ว GitHub จะรันให้อัตโนมัติเมื่อเกิดเหตุการณ์ที่กำหนด — ไม่ต้องตั้งเซิร์ฟเวอร์เอง

Event ที่ใช้บ่อย:

• push — เมื่อ push โค้ดขึ้น branch
• pull_request — เมื่อเปิดหรืออัปเดต PR
• schedule — ตามเวลาที่กำหนดด้วย cron
• workflow_dispatch — กดรันเองจากหน้าเว็บ

3. ภาพรวม 6 ขั้นตอนที่จะทำ

4. ขั้นที่ 1–2 สร้าง branch และไฟล์ workflow

4.1 แยก branch ใหม่ก่อนเสมอ

อย่าแก้บน main โดยตรง เพราะเราต้องการให้ CI ตรวจงานผ่าน Pull Request

git checkout main
git pull
git checkout -b add-ci

ผลลัพธ์ที่ควรเห็น:

Switched to a new branch 'add-ci'

4.2 สร้างโฟลเดอร์และไฟล์ workflow

GitHub มองหา workflow ที่ .github/workflows/ เท่านั้น วางผิดที่จะไม่ถูกรัน

mkdir -p .github/workflows
touch .github/workflows/ci.yml
ls .github/workflows

ci.yml

เคล็ดลับ ชื่อไฟล์จะเป็นอะไรก็ได้ แต่ต้องนามสกุล .yml หรือ .yaml และอยู่ใต้ .github/workflows/ เท่านั้น

4.3 ทางเลือก: สร้างผ่านหน้าเว็บ GitHub

ถ้ายังไม่ถนัดบรรทัดคำสั่ง เปิดหน้า repo → แท็บ Actions → เลือก set up a workflow yourself GitHub จะสร้างไฟล์ให้ในตำแหน่งที่ถูกต้องพร้อมเทมเพลตเริ่มต้น

5. ขั้นที่ 3 เขียนไฟล์ ci.yml ฉบับเต็ม

คัดลอกไฟล์นี้ไปใช้ได้ทันทีกับโปรเจกต์ Node.js แล้วปรับชื่อคำสั่งให้ตรงกับ package.json ของคุณ

name: CI
 
on:
  pull_request:
    branches: [ main ]
 
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
 
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

อ่านทีละส่วน

สำคัญ step ทำงานเรียงจากบนลงล่าง ถ้า step ใดล้ม job จะหยุดทันทีและ step ที่เหลือจะไม่ถูกรัน นี่คือเหตุผลที่เราเรียง lint → test → build จากเร็วไปช้า

ปรับให้เข้ากับภาษาอื่น

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest

      - uses: actions/setup-go@v5
        with:
          go-version: "1.22"
      - run: go test ./...
      - run: go build ./...

6. ขั้นที่ 4–5 push เปิด PR และอ่านผลใน Actions

6.1 Commit และ push

git add .github/workflows/ci.yml
git commit -m "ci: add build and test workflow"
git push -u origin add-ci

Git จะพิมพ์ลิงก์สำหรับเปิด PR กลับมาให้:

remote: Create a pull request for 'add-ci' on GitHub by visiting:
remote:   https://github.com/<user>/<repo>/pull/new/add-ci

หรือเปิด PR จากบรรทัดคำสั่งด้วย GitHub CLI:

gh pr create --fill

https://github.com/<user>/<repo>/pull/7

6.2 ดู workflow ทำงาน

เมื่อ PR ถูกเปิด workflow จะเริ่มรันทันที เปิดแท็บ Actions หรือกดที่ status check บน PR เพื่อดูความคืบหน้าทีละ step

CI / build-and-test
 
  ✓  Set up job                     2s
  ✓  actions/checkout@v4            4s
  ✓  actions/setup-node@v4          9s
  ✓  npm ci                        23s
  ✓  npm run lint                   7s
  ✕  npm test                      12s

6.3 อ่าน log เมื่อขึ้นแดง

1. คลิกที่ step ที่ล้ม (ตัวอย่างข้างบนคือ npm test)
2. เลื่อนหา บรรทัดแรก ที่ขึ้น error หรือ FAIL — นั่นคือสาเหตุจริง บรรทัดที่ตามมามักเป็นผลพวง
3. แก้โค้ดบนเครื่อง แล้ว git push ซ้ำบน branch เดิม
4. workflow จะรันใหม่อัตโนมัติทุกครั้งที่มี commit ใหม่บน branch ของ PR

7. ขั้นที่ 6 ตั้ง required check แล้วทดสอบว่าบล็อกได้จริง

CI จะมีพลังก็ต่อเมื่อ บังคับใช้ มิฉะนั้นทุกคนก็ merge ข้ามได้อยู่ดี

7.1 ตั้ง branch protection

1. เปิด Settings ของ repo แล้วเลือก Branches
2. กด Add branch protection rule
3. ใส่ Branch name pattern เป็น main
4. ติ๊ก Require status checks to pass before merging
5. ค้นหาและเลือก build-and-test จากรายการ (ชื่อนี้มาจาก key ใต้ jobs: ในไฟล์ YAML)
6. กด Create เพื่อบันทึกกฎ

ถ้าหา build-and-test ไม่เจอในรายการ แปลว่า check นั้นยังไม่เคยรันบน repo นี้เลย ให้เปิด PR หนึ่งครั้งให้ workflow รันจบก่อน แล้วกลับมาตั้งค่าใหม่

7.2 ทดสอบว่าบล็อกได้จริง

นี่คือขั้นที่คนส่วนใหญ่ข้าม แต่เป็นขั้นที่พิสูจน์ว่าระบบทำงาน

1. แก้เทสต์ให้ล้มหนึ่งข้อโดยตั้งใจ
2. git push ขึ้น PR เดิม
3. สังเกตว่า GitHub แสดง Some checks were not successful และปุ่ม Merge ถูกปิด
4. แก้กลับให้เทสต์ผ่าน แล้ว push ซ้ำ จนขึ้น All checks have passed

8. ปัญหาที่พบบ่อยและวิธีแก้

9. แนวปฏิบัติที่ดี

1. เริ่มจากง่าย — แค่ build + test ก็มีคุณค่ามหาศาลแล้ว อย่าพยายามใส่ทุกอย่างตั้งแต่วันแรก
2. ทำให้ CI เร็ว — เปิด cache และเรียง step จากเร็วไปช้า ถ้า CI ใช้เวลาเกิน 10 นาที คนจะเริ่มเลี่ยงมัน
3. ตั้งเป็น required check — CI ที่ merge ข้ามได้ ไม่ต่างจากไม่มี CI
4. แก้ CI แดงทันที — อย่าปล่อยให้ main พังค้างไว้ เพราะทุกคนจะติดตามไปด้วย
5. ให้ชื่อ job สื่อความหมาย — ชื่อ job คือชื่อ status check ที่ทุกคนเห็นบน PR
6. ตรึงเวอร์ชัน action — ใช้ @v4 ไม่ใช่ @main เพื่อไม่ให้ workflow พังเองจากการอัปเดตต้นทาง

10. สรุป

แนวคิดสำคัญของทั้งหมดนี้คือ ให้เครื่องตรวจงานซ้ำ ๆ แทนเรา ทีมจะส่งงานได้เร็วขึ้นโดยไม่เสียคุณภาพ

ขั้นถัดไป: Docker Images & Registries — สร้าง image, จัดการ tag และ push ขึ้น registry เพื่อต่อยอด CI ไปสู่ CD