CI/CD คืออะไร? เริ่มทำ Pipeline แรกด้วย GitHub Actions

ลองนึกภาพเย็นวันศุกร์ เพื่อนในทีมแก้บั๊กเล็กๆ เสร็จแล้วรีบ Merge (รวมโค้ด) เข้า main ก่อนกลับบ้าน ไม่มีใครรันเทสต์ เพราะทุกคนคิดว่า "แก้นิดเดียวเอง" สองชั่วโมงต่อมา หน้าเว็บจริงขึ้น Error ทั้งหน้า และคนที่ต้องเปิดโน้ตบุ๊กกลับมาแก้ตอนสามทุ่มคือคุณ

สั้นๆ: CI/CD คือการให้เครื่องรัน Build และ Test ให้อัตโนมัติทุกครั้งที่มีคนส่งโค้ดเข้ามา แล้วส่งโค้ดที่ผ่านการตรวจไปถึงมือผู้ใช้ด้วยขั้นตอนเดิมทุกครั้ง แทนที่จะพึ่งความจำว่าใครรันเทสต์หรือยัง

วันนี้ Superdev Academy จะพาไปดูว่า CI กับ CD ต่างกันตรงไหน ทำไม CD ถึงมีสองความหมาย Pipeline มีขั้นตอนอะไรบ้าง แล้วปิดท้ายด้วยการเขียนไฟล์ GitHub Actions ไฟล์แรกที่รัน npm test ให้เองทุกครั้งที่ Push

CI/CD ย่อมาจากอะไร

CI ย่อมาจาก Continuous Integration ส่วน CD ย่อมาจากได้สองคำ คือ Continuous Delivery หรือ Continuous Deployment ซึ่งไม่ใช่เรื่องเดียวกัน และเป็นจุดที่คนสับสนบ่อยที่สุดของหัวข้อนี้

คำว่า Continuous แปลว่าต่อเนื่อง หัวใจของมันคือทำบ่อยๆ ทีละน้อย แทนที่จะรวมโค้ดหรือปล่อยงานครั้งใหญ่เดือนละครั้งแล้วลุ้นว่าจะพังหรือไม่

CI คืออะไร

GitHub Docs ให้นิยามไว้ว่า Continuous Integration คือแนวปฏิบัติที่นักพัฒนา Commit โค้ดเข้า Repository กลางบ่อยๆ และทุกครั้งที่ Commit ระบบจะ Build และ Test ให้ต่อเนื่อง เพื่อเช็กว่า Commit นั้นไม่ได้พาข้อผิดพลาดใหม่เข้ามา (อ่านต้นฉบับได้ที่ GitHub Docs: Continuous integration)

สิ่งที่ CI ตรวจไม่จำเป็นต้องเป็น Unit Test อย่างเดียว GitHub Docs ยกตัวอย่างไว้ทั้ง Linter ที่ตรวจรูปแบบการเขียน การตรวจความปลอดภัย Code Coverage และ Functional Test พูดง่ายๆ คืออะไรที่คุณเคยต้องจำว่า "ก่อน Merge ต้องรันนะ" ย้ายไปให้เครื่องรันแทนได้หมด

ถ้ายังไม่เคยเขียนเทสต์เลย เริ่มจากบทความ การเขียน Unit Test และ Integration Test อย่างไรให้ได้ผล ก่อนได้ เพราะ CI ที่ไม่มีเทสต์ให้รัน ก็แค่ Build ผ่านแล้วบอกว่าเขียว

CD คืออะไร: Continuous Delivery กับ Continuous Deployment ต่างกันอย่างไร

สองคำนี้ต่างกันแค่ขั้นสุดท้าย คือใครเป็นคนกดปล่อยขึ้น Production (ระบบจริงที่ผู้ใช้ใช้งาน)

• Continuous Delivery: โค้ดทุกชิ้นที่ผ่าน Pipeline อยู่ในสภาพพร้อมปล่อยได้ตลอดเวลา แต่จะปล่อยเมื่อไหร่ ยังให้คนตัดสินใจกด

• Continuous Deployment: ทุกการเปลี่ยนแปลงที่ผ่าน Pipeline ถูกปล่อยขึ้น Production ให้เองอัตโนมัติ ไม่มีคนกดคั่นกลาง

Martin Fowler อธิบายไว้ในบทความ ContinuousDelivery ว่า Continuous Delivery หมายถึงทีม สามารถ Deploy ได้บ่อย แต่อาจเลือกไม่ทำ ส่วน Continuous Deployment คือทุกการเปลี่ยนแปลงวิ่งผ่าน Pipeline แล้วขึ้น Production เอง และเขาย้ำว่าการจะทำ Continuous Deployment ได้ ต้องทำ Continuous Delivery ได้ก่อน

ถ้าเจอคำว่า CD ในเอกสารไหน ให้ดูว่าเขาหมายถึงแบบไหน หน้า Continuous deployment ของ GitHub Docs ใช้ CD ในความหมายของ Continuous Deployment โดยตรง

สำหรับทีมเล็กหรือโปรเจกต์แรก Continuous Delivery มักเป็นจุดเริ่มที่ปลอดภัยกว่า เพราะยังมีคนดูก่อนปล่อยของจริง

CI/CD Pipeline คืออะไร มีขั้นตอนอะไรบ้าง

Pipeline คือลำดับขั้นตอนที่โค้ดต้องเดินผ่านตั้งแต่ถูก Push จนไปถึงผู้ใช้ ถ้าขั้นไหนล้ม ขั้นถัดไปจะไม่ถูกรัน โค้ดที่มีปัญหาจึงไปไม่ถึงปลายทาง Pipeline ของแต่ละทีมหน้าตาต่างกันได้มาก แต่ส่วนใหญ่มีสามขั้นหลักนี้

1. Build: ประกอบโค้ดให้พร้อมรัน

ติดตั้ง Dependency, Compile หรือ Bundle โค้ดให้ออกมาเป็นของที่รันได้ ถ้า Build ไม่ผ่าน แปลว่าโค้ดยังไม่ครบ ไม่ต้องไปต่อ

2. Test: เช็กว่าโค้ดยังทำงานถูก

รัน Unit Test, Lint หรือการตรวจอื่นๆ ที่ทีมตกลงกันไว้ ขั้นนี้คือหัวใจของ CI และเป็นขั้นที่ช่วยเคสเย็นวันศุกร์ข้างบนได้โดยตรง

3. Deploy: ส่งโค้ดขึ้นระบบปลายทาง

ส่งของที่ผ่านสองขั้นแรกไปยัง Staging หรือ Production จะให้คนกดอนุมัติก่อน (Delivery) หรือปล่อยเองเลย (Deployment) ก็เลือกตรงนี้

GitHub Actions คืออะไร

GitHub Actions คือระบบ CI/CD ที่อยู่ในตัว GitHub เอง คุณเขียนขั้นตอนเป็นไฟล์ YAML วางไว้ใน Repository แล้ว GitHub จะเอาไปรันบนเครื่องที่เรียกว่า Runner ทุกครั้งที่เกิดเหตุการณ์ที่กำหนด เช่น Push หรือเปิด Pull Request (ถ้ายังไม่คุ้นกับตัว GitHub อ่าน GitHub คืออะไร ก่อนได้)

ศัพท์ที่ต้องรู้มีแค่สี่คำ ตาม GitHub Docs: Workflow syntax

• Workflow: ไฟล์ .yml หรือ .yaml หนึ่งไฟล์ ต้องเก็บไว้ในโฟลเดอร์ .github/workflows

• on: เหตุการณ์ที่สั่งให้ Workflow เริ่มรัน

• Job: กลุ่มงานที่รันบน Runner หนึ่งเครื่อง ถ้ามีหลาย Job จะรันพร้อมกันเป็นค่าเริ่มต้น

• Step: คำสั่งทีละขั้นใน Job จะเรียก Action สำเร็จรูปด้วย uses หรือรันคำสั่ง Shell ด้วย run ก็ได้

เรื่องค่าใช้จ่าย หน้า Billing ของ GitHub Docs ระบุว่าใช้ฟรีสำหรับ Public Repository ที่รันบน Standard GitHub-hosted Runner ส่วน Private Repository บนแพ็กเกจ GitHub Free ได้โควตา 2,000 นาทีต่อเดือน (ตรวจเมื่อ 1 ตุลาคม 2026 ตัวเลขนี้เปลี่ยนได้ เช็กหน้าเดิมอีกครั้งก่อนวางแผนจริง)

ตัวอย่าง: เขียน Workflow แรกที่รัน npm test

เราจะทำโปรเจกต์ Node.js ที่เล็กที่สุดเท่าที่ทำได้ มีฟังก์ชันเดียว เทสต์เดียว แล้วให้ GitHub Actions รันเทสต์ให้ทุกครั้งที่ Push หรือเปิด Pull Request เข้า main ทุกอย่างข้างล่างนี้ทีมเรารันจริงบนเครื่องด้วย Node.js v26.7.0 และ npm 11.19.0 เมื่อ 1 ตุลาคม 2026

ขั้นที่ 1: เตรียมโค้ดและเทสต์

ไฟล์ sum.js

function sum(a, b) {
  return a + b;
}
module.exports = { sum };

ไฟล์ sum.test.js ใช้ Test Runner ที่มากับ Node.js เอง ไม่ต้องติดตั้งอะไรเพิ่ม

const test = require('node:test');
const assert = require('node:assert');
const { sum } = require('./sum');

test('sum adds two numbers', () => {
  assert.strictEqual(sum(2, 3), 5);
});

ไฟล์ package.json กำหนดให้ npm test เรียก node --test และใช้รายงานผลแบบ TAP ซึ่งเป็นข้อความธรรมดาอ่านง่ายใน Log

{
  "name": "ci-demo",
  "version": "1.0.0",
  "scripts": {
    "test": "node --test --test-reporter=tap"
  }
}

ขั้นที่ 2: สร้างไฟล์ .github/workflows/ci.yml

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm test

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

• on สั่งให้รันเมื่อมี Push หรือ Pull Request เข้า Branch main

• runs-on: ubuntu-latest ขอ Runner ที่เป็น Ubuntu เวอร์ชันล่าสุดที่ GitHub เตรียมไว้

• actions/checkout@v7 ดึงโค้ดใน Repository ลงมาบน Runner

• actions/setup-node@v7 ติดตั้ง Node.js เวอร์ชัน 24 ตามตัวอย่างใน README ของ Action นี้

• npm test รันเทสต์ ถ้าเทสต์ล้ม Step นี้ก็ล้ม

เรื่องเลขเวอร์ชัน ทีมเราเช็กจากหน้า Releases ของแต่ละ Action เมื่อ 1 ตุลาคม 2026: actions/checkout ล่าสุดคือ v7.0.1 (20 กรกฎาคม 2026) และ actions/setup-node ล่าสุดคือ v7.0.0 (14 กรกฎาคม 2026) ที่น่าสังเกตคือตัวอย่าง Node.js ใน GitHub Docs วันเดียวกันยังใช้ actions/checkout@v6 อยู่ ถ้าเลขในเอกสารกับใน Repository ของ Action ไม่ตรงกัน ให้ยึด Repository ของ Action เป็นหลัก

ขั้นที่ 3: รันเทสต์ในเครื่องก่อน Push

ก่อนให้ GitHub รัน ให้แน่ใจก่อนว่าคำสั่งเดียวกันผ่านในเครื่องตัวเอง ผลจริงจากเครื่องเรา (ตัดบรรทัดท้ายออก):

> ci-demo@1.0.0 test
> node --test --test-reporter=tap

TAP version 13
# Subtest: sum adds two numbers
ok 1 - sum adds two numbers
  ---
  duration_ms: 0.480792
  type: 'test'
  ...
1..1
# tests 1
# suites 0
# pass 1
# fail 0

จากนั้นลองแกล้งทำโค้ดพัง เปลี่ยน a + b เป็น a - b แล้วรันใหม่ ผลคือ not ok 1 - sum adds two numbers พร้อมข้อความ -1 !== 5 และ # fail 1 คำสั่งจบด้วย Exit Code 1 ส่วนตอนเทสต์ผ่าน Exit Code คือ 0

ตัวเลขนี้แหละที่ GitHub Actions ใช้ตัดสิน เอกสาร Workflow syntax ระบุว่า Runner รายงานสถานะของ Step ว่าผ่านหรือล้มจาก Exit Code ของคำสั่ง ดังนั้นถ้าเพื่อนเย็นวันศุกร์คนนั้นเปิด Pull Request ที่ทำเทสต์พัง GitHub จะขึ้นสถานะล้มไว้ให้ทุกคนเห็นก่อนกด Merge เราไม่ได้แปะ Log จาก Runner จริงไว้ตรงนี้ เพราะบทความนี้ทดสอบบนเครื่องตัวเอง ไม่ได้รันบน GitHub

ขั้นที่ 4: เช็กว่า YAML อ่านออก

YAML พังเพราะเว้นวรรคผิดได้ง่ายมาก วิธีเช็กเร็วๆ คือให้ Python อ่านไฟล์ดู (ทีมเราใช้ PyYAML 6.0.3)

python3 -c "import yaml; print(yaml.safe_load(open('.github/workflows/ci.yml')))"

Fun Fact: ผลที่ได้จะเห็น Key ชื่อ True แทน on เพราะ PyYAML อ่านตามสเปก YAML 1.1 ที่ถือว่าคำว่า on คือค่า boolean ไฟล์ไม่ได้ผิด GitHub อ่าน on ได้ถูกต้อง แค่อย่าตกใจถ้าเห็นแบบนี้ตอนเช็กในเครื่อง

การเช็กแบบนี้บอกได้แค่ว่า YAML ถูกไวยากรณ์ ไม่ได้บอกว่าชื่อ Key ถูกตามที่ GitHub ต้องการ ส่วนนั้นต้องเทียบกับ Workflow syntax หรือดูผลหลัง Push ในแท็บ Actions ของ Repository

มี CI/CD แล้ว โค้ดจะไม่พังอีกเลยใช่ไหม

ไม่ใช่ CI รันได้แค่เทสต์ที่คุณเขียนไว้ ถ้าบั๊กเกิดในส่วนที่ไม่มีเทสต์ครอบ Pipeline ก็จะขึ้นเขียวอย่างมั่นใจ ทั้งที่โค้ดพัง สถานะเขียวจึงแปลว่า "ผ่านทุกอย่างที่เราสั่งให้ตรวจ" ไม่ได้แปลว่า "ถูกต้องแล้ว"

สิ่งที่ช่วยได้จริงคือการวางรั้วให้ครบ ตั้งให้ Branch main รับเฉพาะ Pull Request ที่ CI ผ่าน เพิ่มเทสต์ทุกครั้งที่เจอบั๊กใหม่ และถ้ายังไม่มั่นใจในชุดเทสต์ ให้เริ่มจาก Continuous Delivery ที่ยังมีคนกดปล่อย ก่อนขยับไป Continuous Deployment ส่วนวิธีวาง Branch ให้ทั้งทีมใช้ร่วมกัน อ่านต่อได้ที่ Git for Team: คู่มือวาง Workflow ไม่ให้โค้ดพัง และถ้าทีมยังเถียงกันว่าจะรวม Branch แบบไหน มีบทความ Git Rebase vs Merge ต่างกันยังไง รออยู่

เมื่อ Workflow แรกรันได้แล้ว ขั้นต่อไปคือเพิ่ม Lint, Build หรือเลือกเครื่องมืออื่นที่เหมาะกับทีม เรามีบทความ 10 วิธีการเพิ่มประสิทธิภาพในกระบวนการพัฒนาโค้ดด้วย CI/CD ที่รวบรวมเทคนิคและเครื่องมืออย่าง Jenkins กับ GitLab CI/CD ไว้ให้ไล่อ่านต่อ

สรุป: CI/CD คืออะไร และควรเริ่มตรงไหน

CI คือการให้เครื่อง Build และ Test ทุกครั้งที่มีโค้ดใหม่ CD คือการส่งโค้ดที่ผ่านแล้วไปถึงผู้ใช้ โดย Continuous Delivery ยังให้คนกดปล่อย ส่วน Continuous Deployment ปล่อยเองทั้งหมด Pipeline ส่วนใหญ่มีสามขั้น Build, Test และ Deploy และ GitHub Actions ทำทั้งหมดนี้ได้จากไฟล์ YAML ไฟล์เดียวใน .github/workflows

ไม่ต้องรอให้โปรเจกต์ใหญ่ก่อนค่อยเริ่ม เอาโปรเจกต์ที่มีอยู่ตอนนี้ เขียนเทสต์สักหนึ่งตัว วางไฟล์ ci.yml ตามตัวอย่างข้างบน แล้ว Push ดู ครั้งแรกที่เห็นเครื่องหมายเขียวขึ้นข้าง Commit คุณจะไม่อยากกลับไป Merge แบบลุ้นๆ อีกเลย

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev Academy Thailand (https://www.facebook.com/superdev.academy.th)

YouTube: Superdev Academy Channel (https://www.youtube.com/@SuperdevAcademy)

Instagram: @superdevacademy (https://www.instagram.com/superdevacademy/)

TikTok: @superdevacademy (https://www.tiktok.com/@superdevacademy?lang=th-TH)