Home » CI/CD Pipeline ด้วย GitHub Actions แบบละเอียด
ไม่มีหมวดหมู่

CI/CD Pipeline ด้วย GitHub Actions แบบละเอียด

March 17, 2026
0 Views

ในโลกของการพัฒนาซอฟต์แวร์ที่เปลี่ยนแปลงอย่างรวดเร็วในปัจจุบัน ประสิทธิภาพ ความน่าเชื่อถือ และความต่อเนื่องคือหัวใจสำคัญของการสร้างสรรค์ผลิตภัณฑ์ที่มีคุณภาพ การนำแนวทาง CI/CD (Continuous Integration/Continuous Delivery) มาใช้จึงไม่ใช่แค่ทางเลือก แต่เป็นสิ่งจำเป็นสำหรับทุกทีมพัฒนาที่ต้องการส่งมอบซอฟต์แวร์ได้อย่างรวดเร็วและมั่นใจ และเมื่อพูดถึงเครื่องมือที่ช่วยให้การสร้าง CI/CD Pipeline เป็นเรื่องง่าย มีประสิทธิภาพ และผสานรวมเข้ากับกระบวนการพัฒนาได้อย่างไร้รอยต่อ GitHub Actions คือหนึ่งในตัวเลือกอันดับต้นๆ ที่ได้รับความนิยมอย่างแพร่หลายครับ

บทความนี้จะพาคุณเจาะลึกถึงแก่นของการสร้าง CI/CD Pipeline ด้วย GitHub Actions ตั้งแต่พื้นฐานของ CI/CD ไปจนถึงการลงมือปฏิบัติจริงด้วยตัวอย่างโค้ดที่สามารถนำไปปรับใช้ได้ทันที ไม่ว่าคุณจะเป็นนักพัฒนาหน้าใหม่ที่เพิ่งเริ่มต้นเรียนรู้ หรือนักพัฒนามากประสบการณ์ที่ต้องการยกระดับกระบวนการทำงานของทีม บทความนี้จะมอบความรู้และเครื่องมือที่คุณต้องการเพื่อปลดล็อกศักยภาพสูงสุดของ GitHub Actions ในการพัฒนาซอฟต์แวร์ของคุณครับ

ทำความเข้าใจ CI/CD Pipeline คืออะไร?

ก่อนที่เราจะลงลึกกับการใช้งาน GitHub Actions สิ่งสำคัญคือเราต้องมีความเข้าใจที่ชัดเจนเกี่ยวกับแนวคิดพื้นฐานของ CI/CD Pipeline เสียก่อนครับ CI/CD คือชุดของหลักปฏิบัติและกระบวนการอัตโนมัติที่ช่วยให้ทีมพัฒนาสามารถส่งมอบการเปลี่ยนแปลงโค้ดไปยังผู้ใช้งานได้อย่างรวดเร็ว ปลอดภัย และมีคุณภาพสูง

Continuous Integration (CI)

Continuous Integration (CI) คือหลักปฏิบัติที่นักพัฒนาจะรวม (integrate) การเปลี่ยนแปลงโค้ดของตนเข้ากับ repository หลัก (เช่น main branch) บ่อยๆ โดยปกติแล้วคือวันละหลายครั้ง ทุกครั้งที่มีการรวมโค้ด ระบบ CI จะทำการรันกระบวนการอัตโนมัติหลายขั้นตอน เช่น:

  • Build: คอมไพล์โค้ด (สำหรับภาษาที่ต้องคอมไพล์) หรือแพ็คเกจแอปพลิเคชัน
  • Test: รันชุดการทดสอบอัตโนมัติทั้งหมด (Unit tests, Integration tests) เพื่อตรวจสอบว่าโค้ดใหม่ไม่ได้ทำให้ฟังก์ชันการทำงานที่มีอยู่เดิมเสียหาย
  • Lint/Static Analysis: ตรวจสอบคุณภาพโค้ด สไตล์การเขียน และหาช่องโหว่ที่อาจเกิดขึ้น

เป้าหมายหลักของ CI คือการตรวจจับข้อผิดพลาดและข้อขัดแย้งในการรวมโค้ด (merge conflicts) ให้เร็วที่สุดเท่าที่จะเป็นไปได้ ลดความซับซ้อนของการแก้ไขปัญหา และทำให้โค้ดเบสพร้อมสำหรับการส่งมอบอยู่เสมอครับ

Continuous Delivery (CD)

Continuous Delivery (CD) เป็นขั้นตอนที่ต่อยอดมาจาก CI ครับ หลังจากที่โค้ดผ่านกระบวนการ CI และถือว่ามีคุณภาพดีพอแล้ว Continuous Delivery จะทำให้มั่นใจว่าการเปลี่ยนแปลงเหล่านั้นพร้อมที่จะถูกนำไปใช้งาน (deploy) ในสภาพแวดล้อมต่างๆ ได้ตลอดเวลา ไม่ว่าจะเป็น staging, UAT (User Acceptance Testing) หรือ production โดยอัตโนมัติ หรือด้วยการกดปุ่มเพียงครั้งเดียว

กระบวนการ CD มักจะรวมถึง:

  • Packaging: สร้าง Artifact ที่พร้อมสำหรับการ Deploy (เช่น Docker image, JAR file, zip archive)
  • Configuration Management: จัดการการตั้งค่าที่แตกต่างกันสำหรับแต่ละสภาพแวดล้อม
  • Deployment to Staging/UAT: Deploy แอปพลิเคชันไปยังสภาพแวดล้อมทดสอบที่เหมือนจริง
  • Automated Acceptance Tests: รัน End-to-End tests หรือ Acceptance tests เพิ่มเติมเพื่อยืนยันว่าแอปพลิเคชันทำงานได้ถูกต้องตามความต้องการทางธุรกิจ

หัวใจสำคัญของ Continuous Delivery คือ “ความพร้อม” ครับ โค้ดที่ผ่าน CD จะต้องพร้อมสำหรับการ Deploy สู่ Production ได้ทุกเมื่อ แต่การ Deploy จริงๆ นั้นยังต้องอาศัยการตัดสินใจของมนุษย์อยู่ครับ

Continuous Deployment (CD)

Continuous Deployment (CD) คือขั้นสูงสุดของ CI/CD ครับ มันคือการต่อยอดจาก Continuous Delivery โดยที่ทุกครั้งที่โค้ดผ่านการทดสอบทั้งหมดใน Pipeline และถือว่าพร้อมสำหรับการ Deploy ระบบจะทำการ Deploy การเปลี่ยนแปลงนั้นไปยังสภาพแวดล้อม Production โดยอัตโนมัติ โดยไม่มีการแทรกแซงจากมนุษย์เลย

การจะไปถึงระดับ Continuous Deployment ได้นั้น ทีมต้องมีความเชื่อมั่นในกระบวนการทดสอบอัตโนมัติในระดับสูงมากๆ และมีระบบ Monitoring ที่แข็งแกร่งเพื่อตรวจจับปัญหาที่อาจเกิดขึ้นได้อย่างรวดเร็ว การนำ Continuous Deployment มาใช้ช่วยให้องค์กรสามารถส่งมอบฟีเจอร์ใหม่ๆ และแก้ไขบั๊กได้อย่างรวดเร็วที่สุด เพิ่มความได้เปรียบในการแข่งขันได้อย่างมหาศาลครับ

ประโยชน์ของการนำ CI/CD มาใช้

การลงทุนใน CI/CD Pipeline มอบผลตอบแทนที่คุ้มค่าอย่างมหาศาลให้กับทีมพัฒนาและองค์กรโดยรวมครับ ประโยชน์หลักๆ ได้แก่:

  • ส่งมอบซอฟต์แวร์ได้รวดเร็วขึ้น: ลดระยะเวลาจากแนวคิดสู่การใช้งานจริง (Time-to-Market) ทำให้ลูกค้าได้รับฟีเจอร์ใหม่ๆ และการปรับปรุงแก้ไขอย่างทันท่วงที
  • คุณภาพซอฟต์แวร์ที่ดีขึ้น: การทดสอบอัตโนมัติอย่างสม่ำเสมอช่วยตรวจจับและแก้ไขข้อผิดพลาดได้ตั้งแต่เนิ่นๆ ลดโอกาสที่บั๊กจะหลุดไปถึง Production
  • ลดความเสี่ยงในการ Deploy: การ Deploy ขนาดเล็กและบ่อยครั้งมีความเสี่ยงน้อยกว่าการ Deploy ครั้งใหญ่ๆ ทำให้การแก้ไขปัญหาทำได้ง่ายขึ้น
  • เพิ่มความน่าเชื่อถือ: กระบวนการที่เป็นอัตโนมัติช่วยลดข้อผิดพลาดที่เกิดจากมนุษย์ ทำให้การ Deploy มีความสม่ำเสมอและน่าเชื่อถือมากขึ้น
  • ลดต้นทุน: ลดเวลาที่ใช้ในการทดสอบและ Deploy ด้วยตนเอง ทำให้ทีมสามารถมุ่งเน้นไปที่การพัฒนาฟีเจอร์ใหม่ๆ ได้มากขึ้น
  • ความร่วมมือที่ดีขึ้น: การรวมโค้ดบ่อยครั้งช่วยลดปัญหาการรวมโค้ดที่ซับซ้อน และส่งเสริมการทำงานร่วมกันภายในทีม

ด้วยประโยชน์เหล่านี้ จึงไม่น่าแปลกใจที่ CI/CD กลายเป็นมาตรฐานทองคำในการพัฒนาซอฟต์แวร์ยุคใหม่ครับ

ทำไมต้อง GitHub Actions สำหรับ CI/CD?

เมื่อเราเข้าใจถึงความสำคัญของ CI/CD แล้ว คำถามถัดมาคือ เราจะเลือกเครื่องมือใดมาช่วยในการสร้าง Pipeline เหล่านี้? ในบรรดาเครื่องมือ CI/CD ที่มีอยู่มากมาย GitHub Actions ได้ก้าวขึ้นมาเป็นหนึ่งในตัวเลือกที่โดดเด่นและได้รับความนิยมอย่างรวดเร็ว โดยเฉพาะสำหรับโปรเจกต์ที่ใช้ GitHub เป็นระบบควบคุมเวอร์ชัน (Version Control System) อยู่แล้วครับ

คุณสมบัติเด่นของ GitHub Actions

GitHub Actions มีคุณสมบัติหลายอย่างที่ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการสร้าง CI/CD Pipeline:

  • ผสานรวมกับ GitHub อย่างไร้รอยต่อ: เนื่องจาก GitHub Actions เป็นส่วนหนึ่งของ GitHub โดยตรง ทำให้การตั้งค่าและการทำงานร่วมกับ Repository, Pull Requests, Issues และส่วนอื่นๆ ของ GitHub เป็นไปอย่างราบรื่นและง่ายดาย
  • Event-Driven Automation: สามารถกำหนดให้ Workflow ทำงานได้โดยอัตโนมัติเมื่อเกิดเหตุการณ์ต่างๆ ใน Repository เช่น การ push โค้ด, การสร้าง Pull Request, การสร้าง Release, หรือแม้กระทั่งการตั้งเวลา (schedule)
  • Configuration as Code (YAML): Workflows ถูกกำหนดโดยไฟล์ YAML ที่เก็บไว้ใน Repository ทำให้สามารถควบคุมเวอร์ชันของ Pipeline ได้เหมือนโค้ดทั่วไป และสามารถตรวจสอบการเปลี่ยนแปลงผ่าน Code Review ได้
  • Marketplace ของ Actions ที่หลากหลาย: GitHub Marketplace มี Actions สำเร็จรูปหลายพันรายการที่พัฒนาโดย GitHub และชุมชน ทำให้คุณสามารถนำมาใช้งานได้ทันทีสำหรับการทำงานทั่วไป เช่น การ Checkout โค้ด, การตั้งค่าสภาพแวดล้อม (Node.js, Python, Java), การ Deploy ไปยัง Cloud Providers ต่างๆ (AWS, Azure, GCP) และอื่นๆ อีกมากมาย ช่วยลดเวลาในการเขียนสคริปต์จากศูนย์
  • ความยืดหยุ่นและปรับแต่งได้สูง: นอกจาก Actions สำเร็จรูปแล้ว คุณยังสามารถเขียน Custom Actions ของตัวเองได้ง่ายๆ ด้วย Docker หรือ JavaScript เพื่อตอบสนองความต้องการเฉพาะของโปรเจกต์
  • Scalability: GitHub จัดการ Runner (เซิร์ฟเวอร์ที่รัน Workflow ของคุณ) ให้โดยอัตโนมัติ ทำให้คุณไม่ต้องกังวลเรื่องการจัดการโครงสร้างพื้นฐาน
  • Cost-Effective: GitHub Actions มี Free tier ที่ค่อนข้าง generous สำหรับ Public repositories และยังเสนอ Free minutes สำหรับ Private repositories ด้วย ทำให้เป็นตัวเลือกที่คุ้มค่าสำหรับหลายๆ โปรเจกต์
  • รองรับหลากหลายภาษาและแพลตฟอร์ม: ไม่ว่าโปรเจกต์ของคุณจะใช้ภาษาอะไร (Node.js, Python, Java, .NET, Go, Ruby, PHP) หรือต้องการ Deploy ไปยังแพลตฟอร์มใด (Cloud providers, Kubernetes, VM) GitHub Actions ก็มีเครื่องมือและ Actions ที่รองรับครับ

สถาปัตยกรรมของ GitHub Actions

การทำความเข้าใจส่วนประกอบหลักของ GitHub Actions จะช่วยให้เราสามารถออกแบบและสร้าง Workflow ได้อย่างมีประสิทธิภาพครับ ส่วนประกอบสำคัญได้แก่:

  • Workflow: คือกระบวนการอัตโนมัติที่กำหนดขึ้นโดยไฟล์ YAML เป็นชุดของ Job ที่จะถูกรันเมื่อเกิด Event ที่กำหนดไว้
  • Event: คือเหตุการณ์ที่เกิดขึ้นใน Repository ของคุณ ซึ่งจะกระตุ้นให้ Workflow เริ่มทำงาน เช่น push, pull_request, issue_comment หรือ schedule
  • Job: คือชุดของ Step ที่รันบน Runner เดียวกัน Job สามารถรันแบบขนานกัน (parallel) หรือรันตามลำดับ (sequential) โดยกำหนด Dependencies ระหว่าง Job ได้
  • Step: คือหน่วยย่อยที่สุดของงานใน Job อาจจะเป็นการรันคำสั่ง Shell script (run) หรือการเรียกใช้ Action สำเร็จรูป (uses)
  • Action: คือแอปพลิเคชันแบบกำหนดเองที่ทำหน้าที่เฉพาะเจาะจง เช่น actions/checkout สำหรับการดึงโค้ด หรือ actions/setup-node สำหรับการตั้งค่า Node.js environment
  • Runner: คือเซิร์ฟเวอร์ที่ติดตั้ง GitHub Actions Runner application และรัน Job ที่กำหนดไว้ GitHub มี Hosted Runners (Ubuntu, Windows, macOS) ให้ใช้ฟรี หรือคุณสามารถใช้ Self-hosted Runners ของตัวเองได้

เมื่อเราเข้าใจส่วนประกอบเหล่านี้แล้ว เราก็พร้อมที่จะลงมือสร้าง CI/CD Pipeline ของเราเองแล้วครับ

ส่วนประกอบสำคัญของ GitHub Actions (Anatomy of a Workflow)

มาเจาะลึกโครงสร้างของ GitHub Actions Workflow file กันครับ ไฟล์นี้เป็นหัวใจสำคัญในการกำหนดว่า CI/CD Pipeline ของเราจะทำงานอย่างไร

Workflow File (.yml)

Workflow ทั้งหมดจะถูกกำหนดในไฟล์ YAML และต้องอยู่ในไดเรกทอรี .github/workflows/ ของ Repository ของคุณ ชื่อไฟล์จะเป็นอะไรก็ได้ เช่น ci.yml, deploy.yml หรือ main.yml ครับ

โครงสร้างพื้นฐานของไฟล์ Workflow มีดังนี้:

name: My First Workflow # ชื่อ Workflow ที่จะแสดงใน GitHub UI

on: # เหตุการณ์ที่กระตุ้น Workflow
  push:
    branches:
      - main

jobs: # ชุดของ Job ที่จะรัน
  build: # ชื่อ Job
    runs-on: ubuntu-latest # Runner ที่ใช้รัน Job
    steps: # ชุดของ Step ใน Job นี้
      - name: Checkout code # ชื่อ Step
        uses: actions/checkout@v4 # ใช้ Action สำเร็จรูป

      - name: Setup Node.js # อีก Step หนึ่ง
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install # รันคำสั่ง Shell

Events

ส่วน on: ใน Workflow file คือส่วนที่เรากำหนดว่า Workflow นี้จะถูกกระตุ้นเมื่อเกิดเหตุการณ์ใดบ้าง GitHub Actions รองรับเหตุการณ์ที่หลากหลายมากครับ

  • push: เมื่อมีการ push โค้ดไปยัง branch ที่กำหนด
  • pull_request: เมื่อมีการสร้าง, อัปเดต, หรือปิด Pull Request
  • workflow_dispatch: อนุญาตให้รัน Workflow ได้ด้วยตนเองจาก GitHub UI
  • schedule: รันตามเวลาที่กำหนด (เช่น ทุกวันตอนเที่ยงคืน)
  • release: เมื่อมีการสร้าง Release ใหม่
  • issue_comment: เมื่อมีการแสดงความคิดเห็นใน Issue หรือ Pull Request

ตัวอย่างการกำหนด Event:

on:
  push:
    branches:
      - main # เมื่อมีการ push ไปยัง branch 'main'
  pull_request:
    branches:
      - main # เมื่อมีการสร้าง PR ที่จะรวมเข้า 'main'
  workflow_dispatch: {} # อนุญาตให้รันด้วยตนเอง
  schedule:
    - cron: '0 0 * * *' # รันทุกวันตอนเที่ยงคืน UTC

Jobs

ส่วน jobs: คือการกำหนดชุดของงานที่จะต้องทำ โดยแต่ละ Job จะรันแยกกันและมีสภาพแวดล้อมเป็นของตัวเอง Job สามารถรันพร้อมกันได้โดยค่าเริ่มต้น หรือกำหนดให้รันตามลำดับโดยใช้คีย์เวิร์ด needs

  • runs-on: ระบุประเภทของ Runner ที่จะใช้ (เช่น ubuntu-latest, windows-latest, macos-latest)
  • steps: รายการของ Step ที่จะรันใน Job นั้น
  • needs: กำหนด Job อื่นที่ Job นี้ต้องรันให้เสร็จสมบูรณ์ก่อน

ตัวอย่าง Job ที่มี Dependencies:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Building..."

  test:
    runs-on: ubuntu-latest
    needs: build # Job 'test' จะรันหลังจาก 'build' เสร็จสิ้น
    steps:
      - run: echo "Testing..."

  deploy:
    runs-on: ubuntu-latest
    needs: test # Job 'deploy' จะรันหลังจาก 'test' เสร็จสิ้น
    steps:
      - run: echo "Deploying..."

Steps

Step คือหน่วยที่เล็กที่สุดของการทำงานภายใน Job แต่ละ Step จะรันคำสั่งหรือ Action เดียว และมีบริบทการทำงานร่วมกับ Step อื่นๆ ใน Job เดียวกัน

  • name: ชื่อของ Step ที่จะแสดงใน UI
  • run: ใช้สำหรับรันคำสั่ง Shell script (เช่น npm install, make build)
  • uses: ใช้สำหรับเรียกใช้ Action สำเร็จรูปจาก Marketplace หรือ Custom Action
  • with: ส่งค่า Input ให้กับ Action ที่เรียกใช้

Actions

Actions คือแอปพลิเคชันแบบกำหนดเองที่ทำงานเฉพาะอย่าง เช่น การดึงโค้ดจาก Git (actions/checkout), การตั้งค่า Node.js environment (actions/setup-node) หรือการส่งข้อความแจ้งเตือน

คุณสามารถใช้ Actions ที่มีอยู่ใน GitHub Marketplace หรือเขียน Custom Actions ของคุณเองได้ครับ

ตัวอย่างการใช้ Action:

      - name: Setup Node.js 18.x
        uses: actions/setup-node@v4 # ใช้ Action ที่เวอร์ชัน 4
        with:
          node-version: '18.x' # ส่ง Input 'node-version' ให้กับ Action
          cache: 'npm' # แคช dependencies ด้วย npm

Runners

Runners คือเซิร์ฟเวอร์ที่รัน Workflow ของคุณ มีสองประเภทหลักๆ ครับ

  • GitHub-hosted Runners: เป็น VM ที่ GitHub จัดหาให้ มีระบบปฏิบัติการยอดนิยม (Ubuntu, Windows, macOS) พร้อมซอฟต์แวร์และเครื่องมือที่จำเป็นติดตั้งมาให้แล้ว คุณไม่ต้องดูแลรักษาเอง และจะถูกสร้างขึ้นมาใหม่สำหรับแต่ละ Job ทำให้มั่นใจได้ถึงสภาพแวดล้อมที่สะอาดทุกครั้ง
  • Self-hosted Runners: คือเครื่องเซิร์ฟเวอร์ที่คุณติดตั้ง GitHub Actions Runner application ด้วยตนเอง สามารถเป็นได้ทั้งเครื่อง Physical, VM หรือ Container ใน Data Center ของคุณหรือบน Cloud เหมาะสำหรับกรณีที่ต้องการสภาพแวดล้อมที่กำหนดเอง, ต้องการเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัว หรือมีข้อจำกัดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด

การเลือกใช้ Runner ขึ้นอยู่กับความต้องการของโปรเจกต์ ส่วนใหญ่แล้ว GitHub-hosted Runners ก็เพียงพอต่อความต้องการทั่วไปแล้วครับ

การสร้าง CI Pipeline ด้วย GitHub Actions (ตัวอย่างละเอียด)

มาถึงส่วนที่น่าตื่นเต้นที่สุด นั่นคือการลงมือสร้าง CI Pipeline ของเราเองครับ ในส่วนนี้ เราจะสร้าง Workflow สำหรับแอปพลิเคชัน Node.js ที่ทำการติดตั้ง Dependencies, Lint โค้ด, รัน Unit Tests และ Build โปรเจกต์ครับ

Scenario: Node.js Application CI

สมมติว่าเรามีโปรเจกต์ Node.js ง่ายๆ ที่ต้องการให้ทุกครั้งที่มีการ Push โค้ดไปยัง main branch หรือมีการสร้าง Pull Request ระบบจะทำการตรวจสอบคุณภาพโค้ดและทดสอบแอปพลิเคชันโดยอัตโนมัติ

เป้าหมายของ CI Pipeline:

  1. Checkout โค้ดจาก Repository
  2. ตั้งค่า Node.js environment
  3. ติดตั้ง Dependencies (npm install)
  4. รัน Static Analysis / Lint (npm run lint)
  5. รัน Unit Tests (npm test)
  6. Build แอปพลิเคชัน (npm run build)
  7. อัปโหลด Artifact ที่ได้จากการ Build เพื่อใช้ในขั้นตอน CD ต่อไป

โครงสร้างโปรเจกต์ (สมมติ)

เราจะมีโครงสร้างไฟล์ Node.js โปรเจกต์แบบง่ายๆ ดังนี้ครับ

my-nodejs-app/
├── .github/
│   └── workflows/
│       └── ci.yml # ไฟล์ Workflow ของเรา
├── src/
│   └── index.js
├── package.json
├── package-lock.json
├── .eslintrc.js
└── test/
    └── index.test.js

และใน package.json จะมี script ที่จำเป็น:

{
  "name": "my-nodejs-app",
  "version": "1.0.0",
  "description": "A simple Node.js app for CI/CD demo",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js",
    "test": "jest",
    "lint": "eslint src/**/*.js test/**/*.js",
    "build": "echo \"Building production assets...\" && mkdir -p dist && cp -r src/* dist/"
  },
  "devDependencies": {
    "eslint": "^8.0.0",
    "jest": "^29.0.0"
  }
}

ไฟล์ Workflow CI

สร้างไฟล์ .github/workflows/ci.yml และเพิ่มโค้ดด้านล่างนี้ลงไปครับ

name: Node.js CI Pipeline

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches:
      - main
      - develop
  workflow_dispatch: # อนุญาตให้รันด้วยตนเองจาก GitHub UI

jobs:
  build-and-test:
    name: Build and Test Node.js App
    runs-on: ubuntu-latest # ใช้ GitHub-hosted runner ที่เป็น Ubuntu ล่าสุด

    steps:
      - name: Checkout code
        uses: actions/checkout@v4 # ดึงโค้ดจาก repository

      - name: Setup Node.js environment
        uses: actions/setup-node@v4 # ตั้งค่า Node.js
        with:
          node-version: '18.x' # ใช้ Node.js เวอร์ชัน 18
          cache: 'npm' # เปิดใช้งานการแคชสำหรับ npm เพื่อความเร็ว

      - name: Display Node.js version
        run: node -v && npm -v # ตรวจสอบเวอร์ชัน Node.js และ npm

      - name: Install dependencies
        run: npm ci # ใช้ 'npm ci' เพื่อการติดตั้งที่น่าเชื่อถือและรวดเร็วกว่า 'npm install' ใน CI/CD

      - name: Run ESLint
        run: npm run lint # รัน Lint เพื่อตรวจสอบคุณภาพโค้ด
        continue-on-error: true # อนุญาตให้ CI ดำเนินต่อไปแม้จะมี Lint warnings/errors (อาจปรับเปลี่ยนได้)

      - name: Run Unit Tests
        run: npm test # รัน Unit Tests

      - name: Build application
        run: npm run build # สร้าง production assets

      - name: Upload build artifact
        uses: actions/upload-artifact@v4 # อัปโหลดไฟล์ที่ได้จากการ Build
        with:
          name: node-app-build # ตั้งชื่อ artifact
          path: dist # ระบุ path ของไฟล์/โฟลเดอร์ที่ต้องการอัปโหลด
          retention-days: 7 # เก็บ artifact ไว้ 7 วัน

คำอธิบาย Workflow CI อย่างละเอียด

มาดูคำอธิบายแต่ละส่วนของ Workflow ci.yml กันครับ

  1. name: Node.js CI Pipeline

    นี่คือชื่อที่ปรากฏในแท็บ Actions ของ GitHub ช่วยให้คุณระบุ Workflow นี้ได้ง่ายครับ

  2. on:

    ส่วนนี้กำหนด Trigger ของ Workflow ครับ

    • push: branches: [main, develop]: Workflow จะทำงานเมื่อมีการ push โค้ดไปยัง main หรือ develop branch
    • pull_request: branches: [main, develop]: Workflow จะทำงานเมื่อมีการสร้างหรืออัปเดต Pull Request ที่มีเป้าหมายไปยัง main หรือ develop branch
    • workflow_dispatch: {}: อนุญาตให้คุณรัน Workflow นี้ได้ด้วยตนเองจากหน้า Actions ของ GitHub ซึ่งมีประโยชน์มากสำหรับการทดสอบหรือรันซ้ำครับ

  3. jobs:

    ใน Workflow นี้มี Job เดียวชื่อ build-and-test

    • name: Build and Test Node.js App: ชื่อที่ปรากฏสำหรับ Job นี้ใน GitHub UI
    • runs-on: ubuntu-latest: กำหนดว่า Job นี้จะรันบน GitHub-hosted runner ที่ใช้ระบบปฏิบัติการ Ubuntu เวอร์ชันล่าสุด

  4. steps:

    นี่คือชุดของคำสั่งและ Actions ที่จะถูกรันตามลำดับภายใน Job build-and-test ครับ

    • - name: Checkout code
      uses: actions/checkout@v4

      เป็น Step แรกที่จำเป็นเสมอในเกือบทุก Workflow ครับ Action actions/checkout@v4 จะทำการดึง (clone) โค้ดจาก Repository ของคุณไปยัง Runner เพื่อให้ Step อื่นๆ สามารถเข้าถึงไฟล์โค้ดได้

    • - name: Setup Node.js environment
      uses: actions/setup-node@v4
      with:
      node-version: '18.x'
      cache: 'npm'

      Action actions/setup-node@v4 ใช้สำหรับตั้งค่าสภาพแวดล้อม Node.js บน Runner เรากำหนดให้ใช้ Node.js เวอร์ชัน 18 และเปิดใช้งานการแคชสำหรับ npm ซึ่งจะช่วยลดเวลาในการติดตั้ง Dependencies ในการรันครั้งถัดไปโดยการจัดเก็บแคชไว้ ทำให้ Workflow ทำงานได้เร็วขึ้นครับ

    • - name: Display Node.js version
      run: node -v && npm -v

      Step นี้เป็นการรันคำสั่ง Shell ธรรมดาเพื่อแสดงเวอร์ชันของ Node.js และ npm ที่กำลังใช้งานอยู่ เพื่อยืนยันว่าการตั้งค่าถูกต้องครับ

    • - name: Install dependencies
      run: npm ci

      npm ci (Clean Install) เป็นคำสั่งที่แนะนำให้ใช้ในสภาพแวดล้อม CI/CD แทน npm install ครับ เพราะจะติดตั้ง Dependencies ตามที่ระบุใน package-lock.json อย่างเคร่งครัด ทำให้มั่นใจได้ว่าทุกครั้งที่รัน CI จะได้ Dependencies ชุดเดียวกัน และยังทำงานได้เร็วกว่าด้วยครับ

    • - name: Run ESLint
      run: npm run lint
      continue-on-error: true

      Step นี้จะรัน script lint ที่เรากำหนดไว้ใน package.json เพื่อตรวจสอบคุณภาพโค้ดด้วย ESLint โดย continue-on-error: true หมายความว่าถึงแม้ ESLint จะพบข้อผิดพลาดหรือคำเตือน Job ก็จะยังคงดำเนินต่อไป ไม่หยุดทำงานทันที (คุณสามารถลบออกได้หากต้องการให้ Lint failures หยุด Pipeline)

    • - name: Run Unit Tests
      run: npm test

      รัน script test เพื่อทำการทดสอบ Unit Tests ของแอปพลิเคชัน หากมี Test ใดๆ ล้มเหลว Job นี้จะล้มเหลวตามไปด้วย และ Workflow จะหยุดลง ทำให้คุณทราบได้ทันทีว่ามีปัญหาเกิดขึ้นกับโค้ด

    • - name: Build application
      run: npm run build

      Step นี้จะรัน script build ที่เรากำหนดไว้ใน package.json เพื่อสร้าง Production assets ของแอปพลิเคชัน (ในตัวอย่างนี้คือการคัดลอกไฟล์จาก src ไปยังโฟลเดอร์ dist)

    • - name: Upload build artifact
      uses: actions/upload-artifact@v4
      with:
      name: node-app-build
      path: dist
      retention-days: 7

      สุดท้าย Step นี้ใช้ Action actions/upload-artifact@v4 เพื่ออัปโหลดไฟล์ที่ได้จากการ Build (ในโฟลเดอร์ dist) เป็น Artifact ครับ Artifact นี้สามารถดาวน์โหลดได้จากหน้า Workflow Run หรือสามารถนำไปใช้ใน Job หรือ Workflow อื่นๆ (โดยเฉพาะ Workflow สำหรับ Continuous Delivery) ได้ในภายหลัง โดยเราตั้งชื่อว่า node-app-build และกำหนดให้เก็บไว้ 7 วันครับ

เมื่อคุณ Push ไฟล์ ci.yml นี้ขึ้น GitHub และมีการ push โค้ดไปยัง main หรือ develop branch (หรือสร้าง PR) คุณจะเห็น Workflow เริ่มทำงานในแท็บ “Actions” ของ Repository ของคุณทันทีครับ

การสร้าง CD Pipeline ด้วย GitHub Actions (ตัวอย่างละเอียด)

หลังจากที่เรามี CI Pipeline ที่น่าเชื่อถือแล้ว ขั้นตอนต่อไปคือการสร้าง CD (Continuous Delivery/Deployment) Pipeline ที่จะนำ Artifact ที่ได้จากการ Build ไป Deploy ครับ ในส่วนนี้ เราจะใช้ตัวอย่างการ Deploy Static Website ไปยัง AWS S3 ครับ

Scenario: Deploy to AWS S3 (Static Website)

สมมติว่าแอปพลิเคชัน Node.js ของเราเป็น Static Website ที่ถูก Build ออกมาเป็นไฟล์ HTML, CSS, JavaScript และรูปภาพ ในโฟลเดอร์ dist เราต้องการ Deploy ไฟล์เหล่านี้ไปยัง S3 Bucket บน AWS ครับ

เป้าหมายของ CD Pipeline:

  1. ดาวน์โหลด Artifact ที่สร้างจาก CI Pipeline
  2. ตั้งค่า AWS Credentials เพื่อให้สามารถเข้าถึง S3 ได้อย่างปลอดภัย
  3. Synchronize ไฟล์จาก Artifact ไปยัง S3 Bucket

เพื่อความยืดหยุ่น เราจะสร้าง Workflow แยกต่างหากสำหรับ CD ซึ่งจะถูกกระตุ้นเมื่อ CI Workflow เสร็จสิ้นอย่างสมบูรณ์

การตั้งค่า AWS Credentials ใน GitHub Secrets

ในการ Deploy ไปยัง AWS เราจำเป็นต้องใช้ Access Key ID และ Secret Access Key ครับ ห้าม hardcode ข้อมูลเหล่านี้ลงในไฟล์ Workflow เด็ดขาด! เราจะใช้ GitHub Secrets เพื่อเก็บข้อมูลที่ละเอียดอ่อนเหล่านี้อย่างปลอดภัย

ไปที่ Repository ของคุณบน GitHub:

  1. คลิกที่แท็บ Settings
  2. ในเมนูด้านซ้าย เลือก Secrets and variables > Actions
  3. คลิก New repository secret
  4. สร้าง Secret สองตัว:
    • AWS_ACCESS_KEY_ID: ใส่ AWS Access Key ID ของคุณ
    • AWS_SECRET_ACCESS_KEY: ใส่ AWS Secret Access Key ของคุณ

คุณควรสร้าง IAM User ใน AWS ที่มีสิทธิ์เฉพาะเจาะจงในการเข้าถึง S3 Bucket ที่คุณต้องการ Deploy เท่านั้น เพื่อจำกัดความเสียหายหาก Credentials เหล่านี้รั่วไหลครับ

อ่านเพิ่มเติมเกี่ยวกับการจัดการ GitHub Secrets

ไฟล์ Workflow CD

สร้างไฟล์ .github/workflows/cd.yml และเพิ่มโค้ดด้านล่างนี้ลงไปครับ

name: Deploy to AWS S3

on:
  workflow_run:
    workflows: ["Node.js CI Pipeline"] # กำหนดให้ CD Workflow ทำงานเมื่อ CI Workflow เสร็จสิ้น
    types:
      - completed # ทำงานเมื่อ CI Workflow เสร็จสมบูรณ์
    branches:
      - main # เฉพาะเมื่อ CI Workflow ทำงานบน main branch

jobs:
  deploy:
    name: Deploy Static Website to S3
    runs-on: ubuntu-latest # ใช้ GitHub-hosted runner
    if: ${{ github.event.workflow_run.conclusion == 'success' }} # รัน Job นี้เฉพาะเมื่อ CI workflow สำเร็จ

    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4 # ดาวน์โหลด artifact ที่สร้างจาก CI workflow
        with:
          name: node-app-build # ต้องตรงกับชื่อ artifact ที่อัปโหลดใน CI workflow
          path: ./dist # ดาวน์โหลด artifact ไปยังโฟลเดอร์ 'dist' ใน Runner

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4 # ตั้งค่า AWS Credentials
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # ดึงค่าจาก GitHub Secret
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # ดึงค่าจาก GitHub Secret
          aws-region: ap-southeast-1 # กำหนด AWS Region ของคุณ

      - name: Deploy to S3
        run: |
          aws s3 sync ./dist s3://your-s3-bucket-name --delete # Sync ไฟล์ไป S3
          echo "Deployment to S3 complete!"
        env:
          AWS_S3_BUCKET: your-s3-bucket-name # แทนที่ด้วยชื่อ S3 Bucket จริงของคุณ

      - name: Invalidate CloudFront Cache (Optional)
        if: success() # รันเฉพาะเมื่อ deploy สำเร็จ
        run: |
          aws cloudfront create-invalidation --distribution-id YOUR_CLOUDFRONT_DISTRIBUTION_ID --paths "/*"
          echo "CloudFront cache invalidated."
        env:
          CLOUDFRONT_DISTRIBUTION_ID: YOUR_CLOUDFRONT_DISTRIBUTION_ID # แทนที่ด้วย CloudFront Distribution ID จริงของคุณ

สำคัญ:

  • แทนที่ your-s3-bucket-name ด้วยชื่อ S3 Bucket จริงของคุณ
  • หากคุณใช้ CloudFront แทนที่ YOUR_CLOUDFRONT_DISTRIBUTION_ID ด้วย ID จริงของคุณ และตรวจสอบให้แน่ใจว่า IAM User มีสิทธิ์ cloudfront:CreateInvalidation ด้วยครับ

คำอธิบาย Workflow CD อย่างละเอียด

มาดูคำอธิบายแต่ละส่วนของ Workflow cd.yml กันครับ

  1. name: Deploy to AWS S3

    ชื่อของ Workflow ที่จะแสดงในแท็บ Actions

  2. on: workflow_run:

    นี่คือ Event trigger ที่สำคัญสำหรับ CD Workflow ครับ

    • workflows: ["Node.js CI Pipeline"]: กำหนดให้ Workflow นี้ทำงานเมื่อ Workflow ที่มีชื่อว่า “Node.js CI Pipeline” (จากไฟล์ ci.yml ของเรา) ทำงานเสร็จสิ้น
    • types: [completed]: จะทำงานเมื่อ Workflow ต้นทางเสร็จสิ้น (ไม่ว่าสำเร็จหรือล้มเหลว)
    • branches: [main]: Workflow นี้จะถูกกระตุ้นเฉพาะเมื่อ CI Workflow ที่เสร็จสมบูรณ์นั้นรันอยู่บน main branch เท่านั้น

    การใช้ workflow_run เป็นวิธีที่แนะนำสำหรับการเชื่อมโยง Workflow สองตัวเข้าด้วยกัน โดยเฉพาะเมื่อคุณต้องการแยก CI และ CD ออกจากกัน เพื่อให้มีความยืดหยุ่นและสามารถจัดการแต่ละส่วนได้อย่างอิสระ

  3. jobs: deploy:

    • name: Deploy Static Website to S3: ชื่อ Job
    • runs-on: ubuntu-latest: ใช้ GitHub-hosted runner
    • if: ${{ github.event.workflow_run.conclusion == 'success' }}: นี่คือ Condition ที่สำคัญมากครับ Job นี้จะรัน เฉพาะเมื่อ Workflow ต้นทาง (CI Pipeline) จบลงด้วยสถานะ success เท่านั้น หาก CI Pipeline ล้มเหลว CD Pipeline จะไม่เริ่มทำงาน ซึ่งเป็นการป้องกันการ Deploy โค้ดที่มีปัญหาครับ

  4. steps:

    • - name: Download build artifact
      uses: actions/download-artifact@v4
      with:
      name: node-app-build
      path: ./dist

      Action actions/download-artifact@v4 ใช้สำหรับดาวน์โหลด Artifact ที่อัปโหลดไว้ใน CI Workflow ครับ เราต้องระบุ name ของ Artifact ให้ตรงกัน (node-app-build) และกำหนด path ที่จะให้ดาวน์โหลดไฟล์เหล่านั้นมาเก็บไว้บน Runner (./dist)

    • - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-southeast-1

      Action aws-actions/configure-aws-credentials@v4 เป็น Action อย่างเป็นทางการจาก AWS ที่ช่วยให้เราสามารถตั้งค่า AWS Credentials บน Runner ได้อย่างปลอดภัย โดยดึงค่าจาก GitHub Secrets ที่เราได้ตั้งค่าไว้ก่อนหน้านี้ และกำหนด AWS Region ที่ต้องการใช้งานครับ

    • - name: Deploy to S3
      run: |
      aws s3 sync ./dist s3://your-s3-bucket-name --delete
      echo "Deployment to S3 complete!"
      env:
      AWS_S3_BUCKET: your-s3-bucket-name

      Step นี้จะรันคำสั่ง AWS CLI เพื่อ Synchronize ไฟล์จากโฟลเดอร์ ./dist บน Runner ไปยัง S3 Bucket ที่กำหนด โดย --delete จะทำให้ไฟล์ที่ไม่พบใน ./dist ถูกลบออกจาก S3 ด้วย เพื่อให้ S3 Bucket มีแต่ไฟล์ที่อัปเดตล่าสุดเท่านั้นครับ เรายังสามารถกำหนด Environment variable AWS_S3_BUCKET เพื่อให้โค้ดอ่านค่าชื่อ Bucket ได้ง่ายขึ้นด้วย

    • - name: Invalidate CloudFront Cache (Optional)
      if: success()
      run: |
      aws cloudfront create-invalidation --distribution-id YOUR_CLOUDFRONT_DISTRIBUTION_ID --paths "/*"
      echo "CloudFront cache invalidated."
      env:
      CLOUDFRONT_DISTRIBUTION_ID: YOUR_CLOUDFRONT_DISTRIBUTION_ID

      หากคุณใช้ AWS CloudFront เพื่อให้บริการ Static Website ของคุณ การ Deploy ไป S3 เพียงอย่างเดียวอาจไม่เพียงพอ เนื่องจาก CloudFront จะแคชไฟล์เก่าไว้ Step นี้จะรันคำสั่งเพื่อสร้าง Invalidation Request ไปยัง CloudFront เพื่อบอกให้ CloudFront ล้างแคชไฟล์ทั้งหมด (/*) ทำให้ผู้ใช้ได้รับไฟล์เวอร์ชันล่าสุดทันทีครับ Condition if: success() จะทำให้ Step นี้รันเฉพาะเมื่อการ Deploy ไป S3 สำเร็จเท่านั้น

เมื่อคุณ Push ไฟล์ cd.yml นี้ขึ้น GitHub และมีการ Push โค้ดไปยัง main branch ซึ่งจะกระตุ้น CI Workflow ให้รัน หลังจาก CI Workflow สำเร็จ คุณจะเห็น CD Workflow เริ่มทำงานตามมาโดยอัตโนมัติ และ Deploy แอปพลิเคชันของคุณไปยัง AWS S3 ครับ

เคล็ดลับและแนวทางปฏิบัติที่ดีที่สุด (Best Practices)

เพื่อการใช้งาน GitHub Actions อย่างมีประสิทธิภาพสูงสุด นี่คือเคล็ดลับและแนวทางปฏิบัติที่ดีที่สุดที่คุณควรนำไปพิจารณาครับ:

  • ใช้ GitHub Secrets สำหรับข้อมูลที่ละเอียดอ่อน: อย่างที่แสดงให้เห็นในตัวอย่าง CD Pipeline ครับ ห้าม Hardcode API Keys, Passwords หรือ Credentials ลงใน Workflow files เด็ดขาด ใช้ GitHub Secrets เสมอเพื่อปกป้องข้อมูลเหล่านี้

  • ระบุเวอร์ชันของ Actions อย่างชัดเจน: แทนที่จะใช้ actions/checkout@main หรือ actions/checkout@latest ควรกำหนดเวอร์ชันที่แน่นอน เช่น actions/checkout@v4 หรือ actions/checkout@28a49c3a2f85c4902203f1947a6d8931b2605f63 (commit SHA) เพื่อให้มั่นใจว่า Workflow ของคุณทำงานได้สม่ำเสมอและไม่ได้รับผลกระทบจากการเปลี่ยนแปลงที่ไม่คาดคิดในเวอร์ชันใหม่ครับ

  • ใช้ npm ci แทน npm install ใน CI: สำหรับโปรเจกต์ Node.js npm ci จะติดตั้ง Dependencies ตาม package-lock.json อย่างเคร่งครัด ทำให้การ Build มีความสม่ำเสมอและมักจะเร็วกว่า npm install ครับ

  • ใช้ Caching สำหรับ Dependencies: Action actions/cache หรือการใช้ with: cache: 'npm' ใน actions/setup-node สามารถช่วยลดเวลาในการติดตั้ง Dependencies ได้อย่างมาก โดยเฉพาะในโปรเจกต์ที่มีขนาดใหญ่ครับ

  • แบ่ง Workflow ออกเป็นส่วนย่อย: หาก Workflow ของคุณเริ่มซับซ้อนเกินไป ให้พิจารณาแบ่งออกเป็น Workflow ย่อยๆ ที่รับผิดชอบงานเฉพาะเจาะจง (เช่น CI Workflow, CD Workflow) แล้วใช้ workflow_run หรือ workflow_call เพื่อเชื่อมโยงกันครับ

  • ใช้ Environments และ Protection Rules: สำหรับการ Deploy ไปยัง Production ควรใช้ GitHub Environments เพื่อกำหนดเงื่อนไขการ Deploy เช่น การอนุมัติด้วยตนเอง (manual approval), การจำกัด Branch ที่สามารถ Deploy ได้ หรือการกำหนดเวลา Deploy

  • ตรวจสอบสถานะของ Workflow: ตรวจสอบแท็บ Actions บน GitHub เพื่อดูสถานะการทำงานของ Workflow และดู Log เพื่อ Debug ปัญหา การใช้ name ที่ชัดเจนสำหรับแต่ละ Step จะช่วยให้การอ่าน Log ทำได้ง่ายขึ้นครับ

  • ใช้ Matrix Strategy สำหรับการทดสอบหลายสภาพแวดล้อม: หากคุณต้องการรัน Test Suite บน Node.js หลายเวอร์ชัน หรือระบบปฏิบัติการที่แตกต่างกัน คุณสามารถใช้ Matrix Strategy เพื่อรัน Job หลายๆ ตัวแบบขนานกันได้ครับ

  • พิจารณา Self-hosted Runners: หากคุณมีข้อกำหนดด้านประสิทธิภาพสูง, ต้องการเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัว, หรือมีข้อจำกัดด้านความปลอดภัย Self-hosted Runners อาจเป็นทางเลือกที่ดีครับ

  • เขียน Test Workflow: ก่อนที่จะนำ Workflow ไปใช้จริง ควรทดสอบ Workflow ของคุณโดยใช้ workflow_dispatch หรือ Push ไปยัง Feature branch ก่อน merge เข้า main

  • การจัดการ Concurrency: หากคุณมี Workflow ที่อาจรันพร้อมกันหลายครั้งและอาจทำให้เกิดปัญหา (เช่น การ Deploy หลายครั้งพร้อมกัน) คุณสามารถใช้ concurrency เพื่อจำกัดจำนวน Workflow ที่รันพร้อมกันได้ครับ

    jobs:
  deploy:
    runs-on: ubuntu-latest
    concurrency: production_deployment # กำหนดกลุ่ม concurrency
    # ... steps

เปรียบเทียบ GitHub Actions กับเครื่องมือ CI/CD อื่นๆ

แม้ GitHub Actions จะมีข้อดีมากมาย แต่ก็ไม่ใช่เครื่องมือเดียวในตลาดครับ การเปรียบเทียบกับเครื่องมือ CI/CD ยอดนิยมอื่นๆ จะช่วยให้คุณเห็นภาพรวมและตัดสินใจเลือกเครื่องมือที่เหมาะสมกับโปรเจกต์ของคุณมากที่สุดได้

คุณสมบัติ GitHub Actions Jenkins GitLab CI/CD CircleCI
การผสานรวม ผสานรวมกับ GitHub อย่างสมบูรณ์แบบ ยืดหยุ่นสูง, รองรับ Git, SVN และอื่นๆ ผ่าน Plugins ผสานรวมกับ GitLab อย่างสมบูรณ์แบบ ผสานรวมกับ GitHub และ Bitbucket
การตั้งค่า YAML file ใน Repository (.github/workflows) Declarative Pipeline (Groovy/YAML), Scripted Pipeline (Groovy) YAML file ใน Repository (.gitlab-ci.yml) YAML file ใน Repository (.circleci/config.yml)
Host/Runner GitHub-hosted และ Self-hosted Runners ต้องจัดการ Runner (Agent) ด้วยตนเอง GitLab-hosted Shared Runners และ Self-hosted Runners CircleCI-hosted และ Self-hosted Runners (Executor)
Ecosystem/Marketplace GitHub Marketplace (Actions สำเร็จรูปจำนวนมาก) Plugin Ecosystem ขนาดใหญ่และหลากหลาย Templates และ Components ภายใน GitLab Orb Marketplace (Reusable configurations)
ความง่ายในการใช้งาน ค่อนข้างง่ายสำหรับผู้เริ่มต้น โดยเฉพาะผู้ใช้ GitHub มีความซับซ้อนในการตั้งค่าเริ่มต้นและบำรุงรักษา ค่อนข้างง่ายสำหรับผู้ใช้ GitLab ค่อนข้างง่าย มี UI ที่เป็นมิตร
Cost Model ฟรีสำหรับ Public repo, มี Free minutes สำหรับ Private repo, คิดค่าใช้จ่ายตามนาทีหลังจากนั้น ฟรี (Open Source), มีค่าใช้จ่ายสำหรับ Infrastructure และการบำรุงรักษา มี Free tier สำหรับ GitLab.com, คิดค่าใช้จ่ายตามนาทีหรือตาม Plan มี Free tier, คิดค่าใช้จ่ายตาม Credit/นาทีที่ใช้
การปรับแต่ง สูง (Custom Actions, Shell scripts) สูงมาก (Groovy, Shell scripts, Plugins) สูง (Custom Docker images, Shell scripts) สูง (Custom Docker images, Shell scripts, Orbs)
เหมาะสำหรับ โปรเจกต์ที่อยู่บน GitHub, ทีมที่ต้องการความเร็วในการตั้งค่าและผสานรวมอย่างแน่นหนา องค์กรขนาดใหญ่, โปรเจกต์ที่มีความต้องการเฉพาะทางสูง, หรือต้องการควบคุม Infrastructure อย่างเต็มที่ โปรเจกต์ที่อยู่บน GitLab, ทีมที่ต้องการ All-in-one DevOps platform ทีมที่ต้องการ CI/CD ที่ใช้งานง่าย, มีประสิทธิภาพ และผสานรวมกับ Cloud ได้ดี

โดยสรุปแล้ว GitHub Actions มีจุดแข็งอยู่ที่การผสานรวมกับ GitHub อย่างไร้รอยต่อ ความง่ายในการเริ่มต้นใช้งาน และ Ecosystem ของ Actions ที่เติบโตอย่างรวดเร็ว ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับหลายๆ ทีม โดยเฉพาะอย่างยิ่งทีมที่ใช้ GitHub เป็นหลักอยู่แล้วครับ

คำถามที่พบบ่อย (FAQ)

Q1: GitHub Actions ฟรีหรือไม่?

A: GitHub Actions มี Free tier ที่ค่อนข้าง generous ครับ สำหรับ Public repositories การใช้งาน GitHub-hosted runners นั้นฟรีทั้งหมดไม่จำกัดนาที สำหรับ Private repositories จะได้รับ Free minutes จำนวนหนึ่งในแต่ละเดือน (เช่น 2,000 นาทีสำหรับบัญชี Free, 3,000 นาทีสำหรับ Pro) หลังจากนั้นจะมีการคิดค่าใช้จ่ายตามนาทีที่ใช้งานจริงตามราคาที่ GitHub กำหนดครับ หากคุณใช้ Self-hosted runners ก็ไม่มีค่าใช้จ่ายจาก GitHub ครับ แต่คุณต้องรับผิดชอบค่าใช้จ่ายในการดูแล Infrastructure ของ Runner ด้วยตนเอง

Q2: จะจัดการ Secrets ใน GitHub Actions ได้อย่างไร?

A: คุณควรใช้ GitHub Secrets เพื่อเก็บข้อมูลที่ละเอียดอ่อน เช่น API Keys, Tokens, Passwords หรือ Credentials ต่างๆ ครับ คุณสามารถเพิ่ม Secrets ได้ที่แท็บ Settings ของ Repository หรือ Organization (Settings > Secrets and variables > Actions) และเรียกใช้ใน Workflow ด้วยไวยากรณ์ ${{ secrets.YOUR_SECRET_NAME }} GitHub Secrets จะถูกเข้ารหัสและไม่สามารถเข้าถึงได้โดยตรงใน Log ของ Workflow ครับ

Q3: GitHub Actions รองรับภาษาและแพลตฟอร์มใดบ้าง?

A: GitHub Actions มีความยืดหยุ่นสูงและรองรับภาษาและแพลตฟอร์มได้หลากหลายมากครับ ไม่ว่าจะเป็น Node.js, Python, Java, .NET, Go, Ruby, PHP หรือภาษาอื่นๆ เนื่องจาก Runner สามารถรันคำสั่ง Shell ได้ทุกประเภท นอกจากนี้ยังมี Actions สำเร็จรูป (เช่น actions/setup-node, actions/setup-python) ที่ช่วยในการตั้งค่าสภาพแวดล้อมเฉพาะสำหรับแต่ละภาษา และมี Actions สำหรับการ Deploy ไปยัง Cloud providers ยอดนิยม (AWS, Azure, GCP) หรือ Kubernetes ด้วยครับ

Q4: Workflow ที่ซับซ้อนควรแบ่งอย่างไร?

A: สำหรับ Workflow ที่ซับซ้อนหรือมีขั้นตอนเยอะๆ ควรพิจารณาแบ่งออกเป็น Workflow ย่อยๆ ครับ เช่น แยก CI Pipeline และ CD Pipeline ออกจากกัน โดยให้ CI ทำหน้าที่ Build, Test, Lint และสร้าง Artifact ส่วน CD ทำหน้าที่ Deploy Artifact นั้นไปยังสภาพแวดล้อมต่างๆ คุณสามารถเชื่อมโยง Workflow เหล่านี้เข้าด้วยกันได้โดยใช้ Event triggers เช่น workflow_run (ให้ Workflow หนึ่งทำงานเมื่ออีก Workflow สำเร็จ) หรือใช้ reusable workflows (workflow_call) เพื่อให้สามารถเรียกใช้ Job หรือ Steps ซ้ำๆ กันในหลาย Workflow ได้ครับ

Q5: จะทดสอบ Workflow ก่อน Push ได้หรือไม่?

A: โดยตรงแล้วไม่มีเครื่องมือสำหรับรัน GitHub Actions Workflow บนเครื่อง Local ก่อน Push ครับ อย่างไรก็ตาม คุณสามารถทำได้หลายวิธีเพื่อลดความเสี่ยง:

  • ใช้ workflow_dispatch: เพิ่ม workflow_dispatch: {} ในส่วน on: ของ Workflow เพื่อให้คุณสามารถรัน Workflow ด้วยตนเองจาก GitHub UI ได้ ทำให้สามารถทดสอบการเปลี่ยนแปลงได้โดยไม่ต้อง Push ไปยัง branch หลัก
  • สร้าง Feature branch: Push การเปลี่ยนแปลง Workflow ไปยัง Feature branch ก่อน แล้วสร้าง Pull Request เพื่อดูว่า Workflow ทำงานถูกต้องหรือไม่ หากมีปัญหา สามารถแก้ไขและ Push ซ้ำบน Feature branch ได้
  • ใช้ GitHub CLI (gh): gh workflow run สามารถช่วยให้คุณเริ่ม Workflow ได้จาก Terminal
  • ใช้ Act: เป็นเครื่องมือ Open Source ที่พยายามจำลอง GitHub Actions environment บนเครื่อง Local แต่ก็อาจจะไม่เหมือนกับสภาพแวดล้อมจริง 100% ครับ

Q6: เมื่อไหร่ที่ควรใช้ Self-hosted Runners?

A: คุณควรพิจารณาใช้ Self-hosted Runners เมื่อ:

  • คุณต้องการฮาร์ดแวร์หรือซอฟต์แวร์เฉพาะที่ไม่มีใน GitHub-hosted runners
  • คุณต้องการเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัว (เช่น Database หรือ Microservices ภายในองค์กร)
  • คุณต้องการควบคุมสภาพแวดล้อมการทำงานของ Runner อย่างเต็มที่
  • คุณมีข้อจำกัดด้านความปลอดภัยหรือการปฏิบัติตามข้อกำหนดที่ต้องการให้โค้ดของคุณรันใน Infrastructure ที่คุณควบคุมเท่านั้น
  • คุณต้องการประหยัดค่าใช้จ่ายในระยะยาว หากมีการใช้งานนาทีสูงมากๆ ใน Private repositories

Q7: Error ทั่วไปที่พบบ่อยในการใช้งาน GitHub Actions มีอะไรบ้าง?

A: Error ทั่วไปที่พบบ่อยได้แก่:

  • YAML Syntax Errors: ไฟล์ YAML ต้องมี Indentation ที่ถูกต้อง มิฉะนั้น Workflow จะไม่สามารถรันได้ ตรวจสอบด้วย YAML Linter เสมอครับ
  • Permissions Issues: Runner ไม่มีสิทธิ์ในการเข้าถึงทรัพยากรที่จำเป็น (เช่น AWS S3, Docker Registry) ตรวจสอบ IAM Policies หรือ GitHub Token Permissions (permissions block)
  • Environment Variables/Secrets Not Found: ตรวจสอบว่าชื่อ Secret หรือ Environment Variable ถูกต้อง และมีการตั้งค่าไว้แล้ว
  • Path Errors: ไฟล์หรือโฟลเดอร์ที่ระบุใน Step หายไปหรือไม่ถูกต้อง ตรวจสอบ Path ใน run หรือ with: path ของ Actions
  • Dependency Installation Failure: ปัญหาในการติดตั้ง Packages (npm install, pip install) อาจเกิดจาก Network issues, Version conflicts หรือ Repository ไม่สามารถเข้าถึงได้
  • Testing Failures: Unit/Integration Tests ล้มเหลว ซึ่งเป็นสัญญาณว่าโค้ดมีปัญหาครับ
  • Out of Disk Space / Memory: โดยเฉพาะกับ Self-hosted runners หรือโปรเจกต์ขนาดใหญ่ อาจต้องมีการจัดการทรัพยากรเพิ่มขึ้น

การตรวจสอบ Log ของ Workflow Run อย่างละเอียดเป็นสิ่งสำคัญที่สุดในการ Debug ปัญหาเหล่านี้ครับ

สรุปและก้าวต่อไป

ตลอดบทความนี้ เราได้เดินทางตั้งแต่การทำความเข้าใจพื้นฐานของ CI/CD ไปจนถึงการลงมือสร้าง CI/CD Pipeline ที่ใช้งานได้จริงด้วย GitHub Actions อย่างละเอียด เราได้เห็นถึงพลังของ GitHub Actions ในการช่วยให้กระบวนการพัฒนาซอฟต์แวร์ของคุณเป็นไปอย่างอัตโนมัติ เพิ่มความเร็ว คุณภาพ และความน่าเชื่อถือในการส่งมอบผลิตภัณฑ์ครับ

GitHub Actions เป็นเครื่องมือที่ทรงพลังและมีความยืดหยุ่นสูง เหมาะอย่างยิ่งสำหรับทีมพัฒนาที่ใช้ GitHub เป็นแพลตฟอร์มหลัก ด้วยความสามารถในการผสานรวมที่ไร้รอยต่อ, ระบบ Event-Driven, Marketplace ของ Actions ที่หลากหลาย และความสามารถในการตั้งค่าแบบ Code-based ทำให้คุณสามารถสร้าง Pipeline ที่ซับซ้อนได้อย่างง่ายดายและมีประสิทธิภาพ ไม่ว่าจะเป็นการทดสอบ, การ Build, การ Deploy ไปยัง Cloud Providers ต่างๆ หรือแม้แต่การแจ้งเตือน

การลงทุนใน CI/CD ไม่ใช่แค่เทรนด์ แต่เป็นการยกระดับมาตรฐานการพัฒนาซอฟต์แวร์ให้ก้าวทันโลกที่เปลี่ยนแปลงไปอย่างรวดเร็ว หากคุณยังไม่ได้นำ CI/CD มาใช้ในโปรเจกต์ของคุณ นี่คือเวลาที่ดีที่สุดที่จะเริ่มต้นครับ

ก้าวต่อไป:

  • เริ่มสร้าง Workflow แรกของคุณ: นำตัวอย่างในบทความนี้ไปปรับใช้กับโปรเจกต์ของคุณเอง
  • สำรวจ GitHub Marketplace: ค้นหา Actions ที่ตรงกับความต้องการเฉพาะของคุณ
  • เรียนรู้เพิ่มเติมเกี่ยวกับ GitHub Actions: เข้าชม เอกสารอย่างเป็นทางการของ GitHub Actions เพื่อเจาะลึกคุณสมบัติขั้นสูง
  • เข้าร่วมชุมชน: แลกเปลี่ยนความรู้และประสบการณ์กับนักพัฒนาคนอื่นๆ

เราหวังว่าบทความนี้จะเป็นประโยชน์และเป็นจุดเริ่มต้นที่ดีในการเดินทางสู่โลกของ CI/CD ด้วย GitHub Actions ของคุณนะครับ หากคุณมีคำถามหรือต้องการคำแนะนำเพิ่มเติม อย่าลังเลที่จะติดต่อทีมงาน SiamLancard.com เรายินดีให้ความช่วยเหลือเสมอครับ!

บทความที่เกี่ยวข้อง

XM Signal — Free Forex EA Download · iCafeForex.com — EA Forex และเครื่องมือเทรด

Related Articles
จัดส่งรวดเร็วส่งด่วนทั่วประเทศ
รับประกันสินค้าเคลมง่าย มีใบรับประกัน
ผ่อนชำระได้บัตรเครดิต 0% สูงสุด 10 เดือน
สะสมแต้ม รับส่วนลดส่วนลดและคะแนนสะสม

ติดต่อเรา | LINE: @siamlancard

Facebook | YouTube | LINE OA

เว็บในเครือ: SiamCafe.net | iCafeForex.com | Siam2R.com | XMSignal.com

© 2026 SiamLancard — จำหน่ายการ์ดแลน อุปกรณ์ Server และเครื่องพิมพ์ใบเสร็จ

SiamLancard
Logo
Free Forex EA Download — XM Signal · EA Forex ฟรี
iCafeForex.com - สอนเทรด Forex | SiamCafe.net
Shopping cart