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

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

March 16, 2026
0 Views

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

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

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

1.1. Continuous Integration (CI) คืออะไร?

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

  • วัตถุประสงค์หลัก: เพื่อตรวจจับและแก้ไขข้อขัดแย้ง (conflicts) หรือข้อผิดพลาด (bugs) ที่เกิดขึ้นจากการรวมโค้ดให้เร็วที่สุดเท่าที่จะเป็นไปได้
  • กระบวนการ: เมื่อนักพัฒนาคอมมิตโค้ด การเปลี่ยนแปลงนั้นจะถูกนำไปรวมเข้ากับโค้ดเบสหลักโดยอัตโนมัติ จากนั้นระบบ CI จะทำการรันกระบวนการต่างๆ เช่น การคอมไพล์โค้ด, การรัน Lint (ตรวจสอบรูปแบบโค้ด), และการรัน Unit Tests หรือ Integration Tests เพื่อตรวจสอบว่าโค้ดใหม่ที่รวมเข้ามานั้นไม่ทำให้ส่วนอื่นๆ ของระบบพังเสียหายครับ
  • ประโยชน์: ลดความเสี่ยงในการเกิด Bug, ตรวจพบข้อผิดพลาดได้เร็วขึ้น, ลดเวลาในการแก้ไข, และช่วยให้นักพัฒนาทำงานร่วมกันได้อย่างราบรื่นขึ้นครับ

1.2. Continuous Delivery (CD) และ Continuous Deployment (CD) คืออะไร?

คำว่า CD สามารถหมายถึงได้ทั้ง Continuous Delivery และ Continuous Deployment ซึ่งมีความคล้ายคลึงกันแต่ก็มีความแตกต่างกันเล็กน้อยครับ

Continuous Delivery (การส่งมอบอย่างต่อเนื่อง)

  • คำนิยาม: เป็นส่วนต่อขยายของ CI ที่มุ่งเน้นไปที่การทำให้ซอฟต์แวร์พร้อมสำหรับการปล่อย (release) ไปยังสภาพแวดล้อมการผลิต (production environment) ได้ตลอดเวลา
  • กระบวนการ: หลังจากการผ่านขั้นตอน CI โค้ดที่ผ่านการทดสอบแล้วจะถูกแพ็กเกจเป็น Artifact ที่พร้อมใช้งาน (เช่น Docker image, WAR file, executable) และนำไปติดตั้งบนสภาพแวดล้อมทดสอบ (staging environment) โดยอัตโนมัติ เพื่อให้ผู้ใช้งานหรือทีม QA สามารถทดสอบเพิ่มเติมได้
  • ความแตกต่าง: การส่งมอบไปยัง Production จะยังคงต้องอาศัยการตัดสินใจและการอนุมัติจากมนุษย์ (manual approval) ครับ
  • ประโยชน์: ลดความซับซ้อนในการปล่อยซอฟต์แวร์, เพิ่มความมั่นใจในคุณภาพของโค้ดที่พร้อมจะปล่อย, และช่วยให้ธุรกิจสามารถตัดสินใจปล่อยฟีเจอร์ใหม่ๆ ได้ตามความเหมาะสมครับ

Continuous Deployment (การปรับใช้/ติดตั้งอย่างต่อเนื่อง)

  • คำนิยาม: เป็นขั้นตอนที่ก้าวหน้าไปอีกขั้นของ Continuous Delivery โดยที่การเปลี่ยนแปลงโค้ดที่ผ่านการทดสอบทั้งหมดแล้วจะถูกปรับใช้ไปยังสภาพแวดล้อมการผลิตโดยอัตโนมัติ โดยไม่มีการแทรกแซงจากมนุษย์
  • กระบวนการ: เมื่อโค้ดผ่านทุกขั้นตอนของ CI และ CD (รวมถึงการทดสอบอัตโนมัติทั้งหมด) ระบบจะทำการปรับใช้โค้ดนั้นไปยัง Production ทันที
  • ความแตกต่าง: ข้อแตกต่างสำคัญคือ “ไม่มีการอนุมัติด้วยมือ” ก่อนการปรับใช้ครับ ซึ่งหมายความว่าทุกครั้งที่มีการคอมมิตและผ่านการทดสอบ โค้ดก็จะถูกปล่อยสู่ Production โดยอัตโนมัติ
  • ประโยชน์: ช่วยให้ฟีเจอร์ใหม่ๆ ไปถึงมือผู้ใช้ได้อย่างรวดเร็วที่สุด, ลดระยะเวลาในการนำเสนอคุณค่าใหม่ๆ ให้กับลูกค้า, และเพิ่มความถี่ในการปล่อยซอฟต์แวร์ได้อย่างมหาศาลครับ

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

1.3. ทำไม CI/CD จึงสำคัญต่อการพัฒนาซอฟต์แวร์?

CI/CD ไม่ใช่แค่ buzzword แต่เป็นหัวใจสำคัญของการพัฒนาซอฟต์แวร์สมัยใหม่ด้วยเหตุผลหลายประการครับ:

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

2. รู้จักกับ GitHub Actions: หัวใจสำคัญของ CI/CD ยุคใหม่

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

2.1. GitHub Actions คืออะไร?

GitHub Actions คือแพลตฟอร์มสำหรับระบบอัตโนมัติที่มาพร้อมกับ GitHub โดยตรง ช่วยให้คุณสามารถสร้าง workflow ที่กำหนดเอง เพื่อทำงานต่างๆ ได้โดยอัตโนมัติ เช่น การสร้างโค้ด (build), การทดสอบ (test), และการปรับใช้ (deploy) โปรเจกต์ของคุณโดยตรงจาก GitHub Repository ครับ

กล่าวคือ เมื่อมีเหตุการณ์ (event) บางอย่างเกิดขึ้นใน Repository ของคุณ เช่น การ push โค้ด, การสร้าง pull request, หรือแม้กระทั่งการกำหนดเวลา (schedule) GitHub Actions จะสามารถเรียกใช้ workflow ที่คุณกำหนดไว้ให้ทำงานได้โดยอัตโนมัติ ทำให้การทำ CI/CD เป็นเรื่องง่ายและเป็นส่วนหนึ่งของกระบวนการพัฒนาโค้ดของคุณเลยทีเดียวครับ

2.2. ส่วนประกอบสำคัญของ GitHub Actions

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

  • Workflows: คือชุดของคำสั่งอัตโนมัติที่คุณกำหนดไว้ในไฟล์ YAML (.yml หรือ .yaml) ซึ่งอยู่ในไดเรกทอรี .github/workflows/ ของ Repository ของคุณ Workflows จะระบุว่าเมื่อใดที่ควรจะรัน (events), งานอะไรที่ต้องทำ (jobs), และลำดับขั้นตอนของงานนั้นๆ (steps) ครับ
  • Events: คือเหตุการณ์ที่เกิดขึ้นใน Repository ของคุณ ซึ่งเป็นตัวกระตุ้นให้ workflow ทำงาน ตัวอย่างเช่น การ push โค้ดไปยัง branch, การเปิด pull request, การสร้าง issue, หรือแม้แต่การกำหนดเวลาให้รัน workflow ตามช่วงเวลาที่กำหนดครับ
  • Jobs: คือชุดของขั้นตอน (steps) ที่รันบน runner เดียวกัน งานแต่ละงานจะรันแยกกันและเป็นอิสระต่อกัน แต่คุณสามารถกำหนดให้งานหนึ่งๆ ขึ้นอยู่กับผลลัพธ์ของงานอื่นได้ครับ (เช่น job B จะรันได้ต่อเมื่อ job A สำเร็จ)
  • Steps: คือลำดับของงานที่จะดำเนินการภายใน job หนึ่งๆ แต่ละ step อาจจะเป็นการรันคำสั่ง shell script หรือการเรียกใช้ “action” ก็ได้ครับ
  • Actions: คือส่วนประกอบที่นำกลับมาใช้ใหม่ได้ (reusable components) ที่สามารถใช้เพื่อทำงานที่ซับซ้อนขึ้นได้ Action ถูกสร้างโดยชุมชน GitHub หรือโดย GitHub เอง และสามารถค้นหาได้ใน GitHub Marketplace ตัวอย่างเช่น action สำหรับ checkout โค้ด, setup Node.js, หรือ deploy ไปยัง cloud provider ครับ
  • Runners: คือเซิร์ฟเวอร์ที่รัน workflow ของคุณ GitHub มี hosted runners ให้บริการ (Ubuntu, Windows, macOS) หรือคุณสามารถตั้งค่า self-hosted runners ของคุณเองได้ครับ

2.3. ประโยชน์ของการใช้ GitHub Actions สำหรับ CI/CD

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

  • การรวมเข้ากับ GitHub อย่างไร้รอยต่อ: เนื่องจากเป็นส่วนหนึ่งของ GitHub ทำให้การตั้งค่าและจัดการ CI/CD Workflow ทำได้ง่ายและรวดเร็ว ไม่ต้องสลับไปมาระหว่างแพลตฟอร์มต่างๆ ครับ
  • Infrastructure as Code (IaC): Workflow ถูกกำหนดด้วยไฟล์ YAML ซึ่งสามารถจัดเก็บไว้ใน Repository เดียวกับโค้ดของคุณ ทำให้สามารถติดตามการเปลี่ยนแปลง ควบคุมเวอร์ชัน และตรวจสอบได้ง่าย
  • Actions Marketplace: มี Actions สำเร็จรูปให้เลือกใช้มากมายจากทั้ง GitHub และชุมชน ทำให้สามารถสร้าง workflow ที่ซับซ้อนได้อย่างรวดเร็ว โดยไม่ต้องเขียน script เองทั้งหมด
  • ความยืดหยุ่น: รองรับภาษาโปรแกรมและแพลตฟอร์มที่หลากหลาย สามารถรันบนระบบปฏิบัติการที่แตกต่างกัน (Linux, Windows, macOS) และสามารถเชื่อมต่อกับบริการคลาวด์ต่างๆ ได้อย่างง่ายดาย
  • ต้นทุน: สำหรับ Repository สาธารณะ (Public Repository) GitHub Actions ให้บริการฟรีอย่างไม่จำกัด สำหรับ Private Repository ก็มีโควต้าฟรีให้ใช้ในแต่ละเดือน ซึ่งเพียงพอสำหรับโปรเจกต์ขนาดเล็กถึงกลางครับ
  • ความปลอดภัย: มีกลไกในการจัดการ Secrets เพื่อเก็บข้อมูลที่ละเอียดอ่อนได้อย่างปลอดภัย ทำให้ไม่ต้อง hardcode ข้อมูลสำคัญใน workflow

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

อ่านเพิ่มเติมเกี่ยวกับ GitHub Actions ได้ที่นี่

3. เจาะลึกแนวคิดหลักของ GitHub Actions สำหรับ CI/CD

การสร้าง CI/CD Pipeline ที่มีประสิทธิภาพด้วย GitHub Actions จำเป็นต้องเข้าใจแนวคิดหลักเหล่านี้อย่างถ่องแท้ครับ

3.1. Workflows (.github/workflows)

Workflow คือหัวใจของ GitHub Actions ครับ มันคือไฟล์ YAML ที่กำหนดกระบวนการอัตโนมัติทั้งหมดของคุณ โดยจะถูกเก็บไว้ในไดเรกทอรี .github/workflows/ ใน root ของ Repository ของคุณ

# .github/workflows/my-first-workflow.yml
name: My First CI/CD Workflow # ชื่อของ Workflow ที่จะแสดงใน GitHub UI

on: # กำหนด Event ที่จะกระตุ้น Workflow
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs: # กำหนด Jobs ที่จะรัน
  build: # ชื่อ Job
    runs-on: ubuntu-latest # Runner ที่จะใช้ (เช่น Ubuntu, Windows, macOS)

    steps: # ลำดับของ Steps ใน Job นี้
      - name: Checkout code # ชื่อ Step
        uses: actions/checkout@v4 # ใช้ Action สำเร็จรูปเพื่อ Checkout โค้ด

      - name: Setup Node.js environment # ชื่อ Step
        uses: actions/setup-node@v4
        with:
          node-version: '18' # ระบุเวอร์ชัน Node.js

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

      - name: Run tests # ชื่อ Step
        run: npm test

จากตัวอย่างข้างต้น เราจะเห็นโครงสร้างพื้นฐานของไฟล์ YAML ที่กำหนด Workflow: name, on (event), และ jobs ครับ

3.2. Events: ตัวกระตุ้น Workflow

Events คือสิ่งที่จะบอก GitHub Actions ว่าเมื่อไหร่ที่ควรจะรัน Workflow ของคุณครับ มี Events หลากหลายประเภทให้เลือกใช้ เช่น:

  • push: เมื่อมีการ push โค้ดไปยัง branch ที่กำหนด
  • pull_request: เมื่อมีการเปิด, อัปเดต, หรือปิด pull request
  • schedule: กำหนดให้รัน Workflow ตามช่วงเวลาที่กำหนดด้วย cron syntax
  • workflow_dispatch: อนุญาตให้รัน Workflow ด้วยตนเองจาก GitHub UI หรือ GitHub API
  • release: เมื่อมีการสร้าง, อัปเดต, หรือลบ release
  • และอื่นๆ อีกมากมาย

คุณสามารถกำหนด Event ได้อย่างละเอียด เช่น on: push: branches: [main, develop] หมายถึงจะรันเมื่อมีการ push ไปยัง branch main หรือ develop เท่านั้นครับ

3.3. Jobs: หน่วยการทำงานอิสระ

Job คือชุดของขั้นตอน (steps) ที่จะรันบน runner เดียวกัน Job แต่ละ Job จะทำงานแยกกันโดยอิสระ แต่สามารถกำหนดลำดับการทำงานได้ด้วย needs ครับ

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Build project
        run: npm run build

  deploy:
    runs-on: ubuntu-latest
    needs: build # Job 'deploy' จะรันได้ก็ต่อเมื่อ Job 'build' สำเร็จ
    steps:
      - name: Deploy to staging
        run: echo "Deploying..."

ในตัวอย่างนี้ Job deploy จะไม่เริ่มทำงานจนกว่า Job build จะเสร็จสมบูรณ์ ซึ่งเป็นสิ่งสำคัญสำหรับ CI/CD ที่มักจะต้อง build ก่อน deploy ครับ

3.4. Steps: ลำดับของงาน

Step คือหน่วยการทำงานที่เล็กที่สุดใน Job แต่ละ Step จะรันคำสั่ง shell หรือใช้ Action ที่กำหนดไว้ครับ

steps:
  - name: Install dependencies # ชื่อของ Step
    run: npm install # รันคำสั่ง shell

  - name: Build application # ชื่อของ Step
    run: | # สามารถรันหลายคำสั่งได้ด้วย pipe syntax
      npm run lint
      npm run build

การใช้ name ช่วยให้ Workflow ของคุณอ่านและเข้าใจง่ายขึ้นเมื่อดูใน GitHub UI ครับ

3.5. Actions: ส่วนประกอบที่นำกลับมาใช้ใหม่ได้

Actions คือส่วนประกอบที่นำกลับมาใช้ใหม่ได้ที่สามารถใช้เพื่อทำงานที่ซับซ้อนขึ้น โดยไม่จำเป็นต้องเขียน script เองทั้งหมดครับ Actions มี 3 ประเภทหลักๆ:

  • Container Actions: รันภายใน Docker container
  • JavaScript Actions: รันโดยตรงบน runner
  • Composite Actions: รวมหลาย steps เข้าเป็น action เดียว

คุณสามารถใช้ Actions จาก GitHub Marketplace ได้ง่ายๆ ด้วยคีย์เวิร์ด uses ตามด้วยชื่อ action และเวอร์ชัน เช่น actions/checkout@v4 หรือ actions/setup-node@v4

steps:
  - uses: actions/checkout@v4 # ใช้ action สำหรับ checkout โค้ด
  - uses: actions/setup-node@v4 # ใช้ action สำหรับติดตั้ง Node.js
    with:
      node-version: '18' # ส่งค่า parameter ให้กับ action

การใช้เวอร์ชันที่ระบุ (เช่น `@v4`) เป็นสิ่งสำคัญเพื่อความเสถียรของ Workflow ครับ

3.6. Runners: เครื่องมือที่รัน Workflow

Runner คือเซิร์ฟเวอร์ที่ GitHub Actions ใช้ในการรัน Job ของคุณ

  • GitHub-hosted runners: เป็น Runner ที่ GitHub จัดหาให้ คุณเพียงแค่ระบุประเภทของ OS ที่ต้องการ (ubuntu-latest, windows-latest, macos-latest) GitHub จะจัดการเรื่อง Infrastructure ให้ทั้งหมดครับ
  • Self-hosted runners: คุณสามารถติดตั้ง Runner บนเซิร์ฟเวอร์ของคุณเอง (physical, virtual, หรือ cloud) ซึ่งมีประโยชน์เมื่อคุณต้องการใช้ทรัพยากรเฉพาะ, สภาพแวดล้อมเฉพาะ, หรือรันบนเครื่องภายในเครือข่ายส่วนตัวครับ
jobs:
  build:
    runs-on: ubuntu-latest # ใช้ GitHub-hosted runner
  
  deploy-internal:
    runs-on: self-hosted # ใช้ self-hosted runner ของคุณเอง

3.7. Contexts: การเข้าถึงข้อมูลใน Workflow

Contexts เป็นวิธีที่คุณสามารถเข้าถึงข้อมูลเกี่ยวกับ Workflow run, environment, jobs, steps, และอื่นๆ ได้ในระหว่างที่ Workflow กำลังทำงานครับ โดยจะใช้ syntax ${{ <context>.<property> }}

Contexts ที่พบบ่อย ได้แก่:

  • github: ข้อมูลเกี่ยวกับ Repository, event, actor (ผู้กระตุ้น), pull request
  • env: ตัวแปรสภาพแวดล้อมที่กำหนดไว้ใน Workflow หรือบน Runner
  • job: ข้อมูลเกี่ยวกับ Job ปัจจุบัน
  • steps: ข้อมูลเอาต์พุตจาก Step ก่อนหน้า
  • runner: ข้อมูลเกี่ยวกับ Runner ที่กำลังใช้งาน
  • secrets: ข้อมูลลับที่จัดเก็บไว้ใน Repository หรือ Environment
steps:
  - name: Display event details
    run: echo "Workflow triggered by ${{ github.event_name }} by ${{ github.actor }}"
  - name: Get output from previous step
    id: set-output
    run: echo "message=Hello from step 1" >> "$GITHUB_OUTPUT"
  - name: Use output
    run: echo "Message: ${{ steps.set-output.outputs.message }}"

3.8. Secrets: การจัดการข้อมูลที่ละเอียดอ่อน

Secrets คือตัวแปรสภาพแวดล้อมที่ถูกเข้ารหัส เพื่อใช้ในการจัดเก็บข้อมูลที่ละเอียดอ่อน เช่น API Keys, Tokens, หรือรหัสผ่าน โดยที่ไม่ต้อง hardcode ลงไปในไฟล์ Workflow ครับ

คุณสามารถกำหนด Secrets ได้ที่:

  • Repository secrets: สำหรับ Repository นั้นๆ เท่านั้น
  • Environment secrets: สำหรับ Environment ที่เฉพาะเจาะจง
  • Organization secrets: สำหรับทุก Repository ภายใต้องค์กร

การใช้งาน Secrets ใน Workflow ทำได้โดยใช้ Context secrets เช่น ${{ secrets.API_KEY }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to cloud
        env:
          MY_API_KEY: ${{ secrets.MY_API_KEY }} # ส่ง Secret เป็น Environment variable
        run: |
          echo "Deploying with API Key..."
          # ใช้ $MY_API_KEY ใน script ของคุณ

Secrets จะถูกเข้ารหัสและจะไม่แสดงใน log ของ Workflow run ซึ่งเป็นสิ่งสำคัญสำหรับความปลอดภัยครับ

4. สร้าง CI Pipeline ด้วย GitHub Actions (ตัวอย่าง: Node.js/React Application)

มาลองสร้าง CI Pipeline สำหรับแอปพลิเคชัน Node.js/React กันครับ Pipeline นี้จะทำการ Checkout โค้ด, ติดตั้ง Dependencies, รัน Lint, รัน Unit Tests และ Build โปรเจกต์

4.1. สถานการณ์จำลอง CI Pipeline

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

  1. ไม่มีข้อผิดพลาดทางไวยากรณ์ (ผ่าน Lint)
  2. ฟังก์ชันการทำงานพื้นฐานยังคงถูกต้อง (ผ่าน Unit Tests)
  3. สามารถ Build ได้สำเร็จ

สิ่งเหล่านี้จะช่วยลดโอกาสที่ Bug จะหลุดรอดไปถึง Production และช่วยให้การทำงานร่วมกันของทีมราบรื่นขึ้นครับ

4.2. โครงสร้าง Workflow สำหรับ CI

เราจะสร้างไฟล์ .github/workflows/ci.yml โดยมีโครงสร้างดังนี้:

  1. Name: กำหนดชื่อ Workflow
  2. On: กำหนดให้ Workflow รันเมื่อมีการ push หรือ pull_request ไปยัง branch main
  3. Jobs:
    • build: Job เดียวที่จะรันบน ubuntu-latest
    • Steps:
      1. Checkout code: ใช้ actions/checkout@v4
      2. Setup Node.js: ใช้ actions/setup-node@v4 กำหนดเวอร์ชัน Node.js
      3. Install dependencies: รัน npm install
      4. Run Lint: รัน npm run lint (สมมติว่ามี script นี้ใน package.json)
      5. Run tests: รัน npm test
      6. Build project: รัน npm run build

4.3. ตัวอย่างโค้ด CI Workflow (ci.yml)

สร้างไฟล์ชื่อ ci.yml ในไดเรกทอรี .github/workflows/ ของ Repository ของคุณ และคัดลอกโค้ดด้านล่างนี้ไปวางครับ

# .github/workflows/ci.yml
name: Node.js CI Pipeline

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches:
      - main
      - develop

jobs:
  build:
    runs-on: ubuntu-latest # รันบน Ubuntu Linux

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

      - name: Setup Node.js # Step 2: ติดตั้ง Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18' # ระบุเวอร์ชัน Node.js ที่ต้องการ
          cache: 'npm' # เปิดใช้งานการแคช dependencies ของ npm เพื่อความเร็ว

      - name: Install dependencies # Step 3: ติดตั้งแพ็กเกจ Node.js
        run: npm install

      - name: Run ESLint # Step 4: รัน Lint เพื่อตรวจสอบรูปแบบโค้ด
        # สมมติว่าใน package.json มี script "lint": "eslint ."
        run: npm run lint

      - name: Run Unit Tests # Step 5: รัน Unit Tests
        # สมมติว่าใน package.json มี script "test": "react-scripts test --watchAll=false"
        run: npm test

      - name: Build project # Step 6: Build โปรเจกต์
        # สมมติว่าใน package.json มี script "build": "react-scripts build"
        run: npm run build

      - name: Archive production artifacts # Step 7 (Optional): จัดเก็บไฟล์ที่ Build ได้เป็น Artifact
        uses: actions/upload-artifact@v4
        with:
          name: build-artifact
          path: build/ # หรือ dist/ ขึ้นอยู่กับโครงสร้างโปรเจกต์ของคุณ
          retention-days: 5 # เก็บ Artifact ไว้ 5 วัน

คำอธิบายเพิ่มเติม:

  • cache: 'npm' ใน actions/setup-node เป็นสิ่งสำคัญมากครับ มันจะช่วยให้ GitHub Actions แคชโฟลเดอร์ node_modules ไว้ ทำให้การรัน npm install ครั้งถัดไปเร็วขึ้นอย่างมาก
  • npm run lint, npm test, และ npm run build เป็นคำสั่งที่ขึ้นอยู่กับว่าคุณได้กำหนด script ไว้ในไฟล์ package.json อย่างไร หากคุณใช้ Create React App โดยปกติจะมี script เหล่านี้อยู่แล้วครับ
  • actions/upload-artifact@v4 เป็น Action ที่ใช้สำหรับจัดเก็บไฟล์ที่ได้จากการ Build (เช่น โฟลเดอร์ build หรือ dist) เป็น Artifact ซึ่งเป็นประโยชน์อย่างยิ่งหากคุณต้องการนำ Artifact เหล่านี้ไปใช้ใน CD Pipeline ต่อไปครับ

เมื่อคุณคอมมิตไฟล์ ci.yml นี้ไปยัง Repository ของคุณ GitHub Actions จะเริ่มทำงานโดยอัตโนมัติเมื่อมีการ push โค้ดหรือสร้าง Pull Request และคุณจะเห็นสถานะการทำงานของ Pipeline ในแท็บ “Actions” บน GitHub ครับ

5. สร้าง CD Pipeline ด้วย GitHub Actions (ตัวอย่าง: Deploy ไปยัง Vercel/Netlify)

หลังจากที่เรามี CI Pipeline ที่ตรวจสอบคุณภาพโค้ดแล้ว ขั้นตอนต่อไปคือการสร้าง CD Pipeline เพื่อ Deploy แอปพลิเคชันที่ Build สำเร็จไปยังสภาพแวดล้อมจริงครับ ในที่นี้เราจะใช้ Vercel หรือ Netlify ซึ่งเป็นแพลตฟอร์มที่นิยมสำหรับการ Deploy Static Sites หรือ Single Page Applications (SPA) เช่น React App

5.1. สถานการณ์จำลอง CD Pipeline

เราจะสร้าง CD Pipeline ที่จะ Deploy แอปพลิเคชัน React ของเราไปยัง Vercel หรือ Netlify โดยมีเงื่อนไขดังนี้ครับ:

  1. Workflow จะถูกกระตุ้นเมื่อมีการ push โค้ดไปยัง branch main เท่านั้น (ซึ่งหมายความว่าโค้ดได้ผ่าน CI มาแล้ว)
  2. Workflow จะต้องรอให้ Job CI สำเร็จก่อน (ถ้าเราแยกไฟล์ Workflow)
  3. จะใช้ Secrets เพื่อเก็บ API Token สำหรับการ Deploy

การ Deploy ไปยัง Vercel/Netlify มักจะง่ายกว่าการ Deploy ไปยัง Cloud Provider อื่นๆ เช่น AWS หรือ Azure เพราะแพลตฟอร์มเหล่านี้มี CLI หรือ Actions สำเร็จรูปที่ช่วยให้การ Deploy ทำได้ง่ายขึ้นมากครับ

5.2. โครงสร้าง Workflow สำหรับ CD

เราจะสร้างไฟล์ .github/workflows/cd.yml โดยมีโครงสร้างดังนี้:

  1. Name: กำหนดชื่อ Workflow
  2. On: กำหนดให้ Workflow รันเมื่อมีการ push ไปยัง branch main เท่านั้น
  3. Jobs:
    • deploy: Job เดียวที่จะรันบน ubuntu-latest
    • Needs: (Optional, ถ้าแยกไฟล์ CI/CD) ระบุว่าต้องรอให้ Job CI สำเร็จก่อน
    • Steps:
      1. Checkout code: ใช้ actions/checkout@v4
      2. Setup Node.js: ใช้ actions/setup-node@v4
      3. Install dependencies: รัน npm install (ถ้าไม่ได้ใช้ Artifact จาก CI)
      4. Build project: รัน npm run build (ถ้าไม่ได้ใช้ Artifact จาก CI)
      5. Deploy to Vercel/Netlify: ใช้ CLI ของแพลตฟอร์มนั้นๆ และ Secrets

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

5.3. ตัวอย่างโค้ด CD Workflow (cd.yml)

ก่อนที่จะรันโค้ดนี้ คุณจะต้องสร้าง API Token จาก Vercel/Netlify และเพิ่มเป็น Secret ใน Repository ของคุณก่อนครับ

  • สำหรับ Vercel: เข้าไปที่ Vercel Dashboard -> Settings -> Tokens -> Generate New Token. ตั้งชื่อ เช่น VERCEL_TOKEN
  • สำหรับ Netlify: เข้าไปที่ Netlify Dashboard -> User settings -> Applications -> Personal access tokens -> New access token. ตั้งชื่อ เช่น NETLIFY_AUTH_TOKEN

จากนั้นไปที่ GitHub Repository ของคุณ -> Settings -> Secrets and variables -> Actions -> New repository secret และเพิ่ม Secret ด้วยชื่อที่คุณตั้งไว้และค่า Token ที่ได้มาครับ

ตัวอย่างโค้ดสำหรับ Deploy ไปยัง Vercel (cd-vercel.yml)

# .github/workflows/cd-vercel.yml
name: Deploy to Vercel

on:
  push:
    branches:
      - main # Deploy เมื่อมีการ push ไปยัง branch 'main' เท่านั้น

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }} # ID องค์กร Vercel (optional, ถ้ามี)
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }} # ID โปรเจกต์ Vercel (optional, ถ้ามี)

jobs:
  deploy:
    runs-on: ubuntu-latest
    # ถ้าคุณมี CI Workflow แยกต่างหาก และต้องการรอให้มันสำเร็จก่อน
    # คุณสามารถใช้ 'needs' ได้
    # needs: [ci-build-job-name]

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

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

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build project # Vercel จะ Build ให้อัตโนมัติ แต่การ Build ก่อนหน้านี้ช่วยให้มั่นใจได้
        run: npm run build

      - name: Deploy to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
        # --prebuilt: บอก Vercel ว่าเราได้ Build โปรเจกต์มาแล้ว ไม่ต้อง Build ซ้ำ
        # --prod: Deploy ไปยัง Production

ตัวอย่างโค้ดสำหรับ Deploy ไปยัง Netlify (cd-netlify.yml)

# .github/workflows/cd-netlify.yml
name: Deploy to Netlify

on:
  push:
    branches:
      - main # Deploy เมื่อมีการ push ไปยัง branch 'main' เท่านั้น

jobs:
  deploy:
    runs-on: ubuntu-latest
    # ถ้าคุณมี CI Workflow แยกต่างหาก และต้องการรอให้มันสำเร็จก่อน
    # คุณสามารถใช้ 'needs' ได้
    # needs: [ci-build-job-name]

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

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

      - name: Install dependencies
        run: npm install

      - name: Build project
        run: npm run build # Netlify จะ Build ให้อัตโนมัติ แต่การ Build ก่อนหน้านี้ช่วยให้มั่นใจได้

      - name: Deploy to Netlify
        uses: nwtgck/[email protected] # ใช้ Netlify Action
        with:
          publish-dir: './build' # ไดเรกทอรีที่ Build สำเร็จ
          production-branch: 'main'
          github-token: ${{ secrets.GITHUB_TOKEN }} # สำหรับการสร้างสถานะ Deployment บน GitHub
          netlify-auth-token: ${{ secrets.NETLIFY_AUTH_TOKEN }} # Netlify Access Token
          netlify-site-id: ${{ secrets.NETLIFY_SITE_ID }} # Site ID ของคุณ
        id: netlify # ตั้ง ID ให้ Step นี้เพื่อเข้าถึง Output

คำอธิบายเพิ่มเติม:

  • สำหรับ Vercel เราใช้ Vercel CLI และส่ง VERCEL_TOKEN เป็น Environment variable เพื่อทำการ Authenticate และ Deploy
  • สำหรับ Netlify เราใช้ Action สำเร็จรูป nwtgck/[email protected] ซึ่งจะช่วยจัดการกระบวนการ Deploy ได้ง่ายขึ้น โดยต้องระบุ publish-dir และ netlify-auth-token รวมถึง netlify-site-id ซึ่งหาได้จาก Netlify Dashboard ของคุณครับ
  • secrets.GITHUB_TOKEN เป็น Secret ที่ GitHub สร้างให้อัตโนมัติและมีสิทธิ์ในการโต้ตอบกับ API ของ GitHub เช่น การตั้งค่าสถานะของ Pull Request หรือ Deployment

เมื่อคุณคอมมิตไฟล์ CD Workflow นี้ไปยัง branch main (หลังจากผ่าน CI แล้ว) แอปพลิเคชันของคุณจะถูก Deploy ไปยัง Vercel หรือ Netlify โดยอัตโนมัติครับ

ศึกษาการ Deploy ไปยัง AWS S3/EC2 ด้วย GitHub Actions

6. แนวคิด CI/CD ขั้นสูงด้วย GitHub Actions

GitHub Actions มีความสามารถที่หลากหลายเพื่อรองรับ CI/CD Pipeline ที่ซับซ้อนและมีประสิทธิภาพยิ่งขึ้นครับ

6.1. Environments และ Approval Gates

สำหรับโปรเจกต์ขนาดใหญ่ การมีหลายสภาพแวดล้อม (เช่น development, staging, production) เป็นสิ่งจำเป็น GitHub Actions ช่วยให้คุณกำหนด Environments และเพิ่ม Approval Gates ได้

  • Environments: คุณสามารถกำหนด Environment ให้กับ Job ได้ โดยแต่ละ Environment สามารถมี Secrets, ตัวแปร, และกฎการป้องกันที่แตกต่างกันได้
  • Approval Gates: สำหรับ Environment ที่สำคัญ เช่น Production คุณสามารถกำหนดให้ Workflow ต้องได้รับการอนุมัติจากผู้ใช้ที่ระบุ (approvers) ก่อนที่จะรัน Job ใน Environment นั้นได้ สิ่งนี้ช่วยเพิ่มความปลอดภัยและควบคุมการ Deploy ได้อย่างเข้มงวดครับ
jobs:
  deploy-to-staging:
    runs-on: ubuntu-latest
    environment: staging # กำหนด Environment
    steps:
      - name: Deploy to Staging
        run: echo "Deploying to Staging..."

  deploy-to-production:
    runs-on: ubuntu-latest
    environment: # กำหนด Environment พร้อมกฎการป้องกัน
      name: production
      url: https://your-production-url.com # URL ที่เกี่ยวข้องกับ Environment นี้
    needs: deploy-to-staging # Job นี้จะรันได้ต่อเมื่อ Job 'deploy-to-staging' สำเร็จ
    steps:
      - name: Deploy to Production
        run: echo "Deploying to Production..."

ใน GitHub UI คุณสามารถกำหนดผู้ตรวจสอบ (Reviewers) สำหรับแต่ละ Environment ได้ ซึ่งจะทำให้ Job deploy-to-production จะต้องรอการอนุมัติก่อนจึงจะทำงานได้ครับ

6.2. Matrix Builds: การทดสอบหลายเงื่อนไข

Matrix Strategy ช่วยให้คุณรัน Job เดิมซ้ำๆ โดยใช้ชุดตัวแปรที่แตกต่างกันได้ ซึ่งมีประโยชน์มากสำหรับการทดสอบแอปพลิเคชันของคุณในหลายสภาพแวดล้อม เช่น การทดสอบด้วย Node.js หลายเวอร์ชัน, บน OS ที่แตกต่างกัน, หรือด้วยเวอร์ชันของ Dependency ที่แตกต่างกัน

jobs:
  test:
    runs-on: ${{ matrix.os }} # ใช้ OS จาก matrix
    strategy:
      matrix:
        node-version: ['16', '18', '20'] # ทดสอบด้วย Node.js 3 เวอร์ชัน
        os: [ubuntu-latest, windows-latest] # ทดสอบบน Ubuntu และ Windows

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

      - name: Setup Node.js ${{ matrix.node-version }} on ${{ matrix.os }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

Workflow นี้จะสร้าง Job ทั้งหมด 3 x 2 = 6 Job เพื่อทดสอบโค้ดของคุณบนทุกชุดค่าผสมของ Node.js เวอร์ชันและระบบปฏิบัติการที่กำหนดครับ

6.3. Caching Dependencies: เพิ่มความเร็วในการรัน

การติดตั้ง Dependencies (เช่น npm install, pip install, composer install) อาจใช้เวลานาน GitHub Actions มี actions/cache Action ที่ช่วยให้คุณแคช Dependencies ที่ดาวน์โหลดมาได้ ทำให้ Workflow run ครั้งถัดไปเร็วขึ้นอย่างมาก

steps:
  - name: Cache Node.js modules
    uses: actions/cache@v4
    with:
      path: ~/.npm # หรือ node_modules สำหรับ npm หรือ .cache สำหรับ yarn
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} # Key สำหรับ Cache
      restore-keys: |
        ${{ runner.os }}-node-

  - name: Install dependencies
    run: npm install

hashFiles('**/package-lock.json') จะสร้าง Key จากไฟล์ package-lock.json หากไฟล์นี้มีการเปลี่ยนแปลง Cache ก็จะถูกสร้างใหม่ครับ

6.4. Reusable Workflows: การนำ Workflow กลับมาใช้ซ้ำ

สำหรับโปรเจกต์ที่มีหลาย Repository ที่ต้องการใช้ CI/CD Logic คล้ายๆ กัน คุณสามารถสร้าง Reusable Workflows เพื่อนำกลับมาใช้ซ้ำได้ สิ่งนี้ช่วยลดความซ้ำซ้อนและทำให้การจัดการ Workflow ง่ายขึ้น

ไฟล์ Workflow ที่นำไปใช้ซ้ำ (e.g., .github/workflows/build-node-app.yml):

# .github/workflows/build-node-app.yml
name: Reusable Node.js Build

on:
  workflow_call: # กำหนดให้ Workflow นี้สามารถถูกเรียกได้

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm install
      - run: npm run build

ไฟล์ Workflow ที่เรียกใช้ (e.g., .github/workflows/main-app-ci.yml):

# .github/workflows/main-app-ci.yml
name: Main App CI

on:
  push:
    branches: [ main ]

jobs:
  call-build:
    uses: ./.github/workflows/build-node-app.yml # เรียกใช้ Reusable Workflow

คุณยังสามารถเรียกใช้ Reusable Workflow จาก Repository อื่นได้ด้วย เช่น owner/repo/.github/workflows/build-node-app.yml@main

6.5. Self-Hosted Runners: รัน Workflow ในสภาพแวดล้อมของคุณเอง

โดยปกติแล้ว GitHub Actions จะรันบน GitHub-hosted runners แต่ถ้าคุณมีความต้องการพิเศษ เช่น:

  • ต้องเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัว
  • ต้องการใช้ฮาร์ดแวร์เฉพาะ (GPU, RAM สูง)
  • ต้องการใช้ระบบปฏิบัติการที่ไม่รองรับโดย GitHub-hosted runners

คุณสามารถตั้งค่า Self-Hosted Runners ได้ โดยการติดตั้ง GitHub Actions Runner application บนเครื่องของคุณเอง (Linux, Windows, macOS) แล้วให้ Runner นั้นเชื่อมต่อไปยัง GitHub เพื่อรอรับ Job ครับ

jobs:
  build:
    runs-on: self-hosted # ระบุว่าให้รันบน Self-hosted runner
    steps:
      - name: Build on custom machine
        run: echo "Running on my own machine!"

6.6. Monitoring และ Notifications

การตรวจสอบสถานะของ CI/CD Pipeline เป็นสิ่งสำคัญ GitHub Actions มีเครื่องมือในตัวเพื่อช่วยในเรื่องนี้:

  • GitHub UI: แท็บ “Actions” ใน Repository ของคุณแสดงสถานะของทุก Workflow run พร้อมรายละเอียด Job, Step, และ Log
  • Status Checks: คุณสามารถกำหนดให้ Workflow เป็น “Required status checks” สำหรับ Pull Requests ได้ เพื่อให้มั่นใจว่าโค้ดที่รวมเข้ามาผ่าน CI ก่อน
  • Notifications: GitHub สามารถส่งอีเมลหรือแจ้งเตือนใน GitHub UI เมื่อ Workflow fail หรือสำเร็จ
  • Integrations: คุณสามารถเชื่อมต่อ GitHub Actions กับเครื่องมือภายนอก เช่น Slack, Microsoft Teams, หรือ Datadog เพื่อรับการแจ้งเตือนหรือรวบรวม Metrics ได้

6.7. Security Best Practices

ความปลอดภัยเป็นสิ่งสำคัญสูงสุดสำหรับ CI/CD Pipeline ครับ

  • ใช้ Secrets อย่างระมัดระวัง: อย่า hardcode ข้อมูลที่ละเอียดอ่อนในไฟล์ Workflow ใช้ GitHub Secrets เสมอ และจำกัดสิทธิ์การเข้าถึง Secrets ให้เฉพาะ Workflow และ Environment ที่จำเป็นเท่านั้น
  • จำกัดสิทธิ์ของ GITHUB_TOKEN: GITHUB_TOKEN เป็น Secret ที่ GitHub สร้างให้อัตโนมัติ โดยค่าเริ่มต้นจะมีสิทธิ์ค่อนข้างกว้างขวาง คุณควรจำกัดสิทธิ์ของมันให้แคบที่สุดเท่าที่ Workflow ต้องการด้วย permissions block
  • ระบุเวอร์ชันของ Actions: ใช้เวอร์ชันที่แน่นอนของ Actions (เช่น actions/checkout@v4 แทนที่จะเป็น actions/checkout@main) เพื่อป้องกันการเปลี่ยนแปลงที่ไม่คาดคิด
  • ตรวจสอบ Actions ภายนอก: หากใช้ Actions จาก GitHub Marketplace ควรตรวจสอบว่า Action นั้นมาจากผู้พัฒนาที่น่าเชื่อถือและไม่มีช่องโหว่ด้านความปลอดภัย
  • Code Scanning: ใช้ GitHub Code Scanning หรือเครื่องมือ Static Analysis อื่นๆ ใน Workflow เพื่อตรวจจับช่องโหว่ด้านความปลอดภัยในโค้ดของคุณตั้งแต่เนิ่นๆ
  • Least Privilege: ให้สิทธิ์แก่ Runner และ Secrets เท่าที่จำเป็นต่อการทำงานของ Job เท่านั้น

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

GitHub Actions เป็นหนึ่งในเครื่องมือ CI/CD ที่ได้รับความนิยม แต่ก็มีเครื่องมืออื่นๆ ที่มีจุดเด่นแตกต่างกันไปครับ มาดูกันว่า GitHub Actions มีความโดดเด่นอย่างไรเมื่อเทียบกับคู่แข่ง

คุณสมบัติ GitHub Actions Jenkins GitLab CI/CD CircleCI
รูปแบบการใช้งาน YAML file ใน Repo Groovy DSL หรือ UI (Jenkinsfile) YAML file ใน Repo YAML file ใน Repo (config.yml)
การรวมกับ VCS ผสานรวมกับ GitHub ได้อย่างสมบูรณ์แบบ รองรับ Git, SVN, Perforce (ต้องติดตั้ง Plugin) ผสานรวมกับ GitLab ได้อย่างสมบูรณ์แบบ ผสานรวมกับ GitHub/Bitbucket ได้ดี
Hosted Runners มี (Ubuntu, Windows, macOS) ไม่มี (ต้องจัดการเองหรือใช้ Cloud Provider) มี (Linux, Windows, macOS) มี (Linux, Windows, macOS)
Self-Hosted Runners รองรับ รองรับ (Agents/Nodes) รองรับ (Runners) รองรับ (Self-hosted Runners)
Marketplace/Plugins GitHub Marketplace (Actions) Jenkins Plugin Marketplace (มี Plugin นับพัน) Templates/Components (รองรับ Docker images) Orbs (Actions ที่นำกลับมาใช้ซ้ำได้)
ความง่ายในการเริ่มต้น ง่ายมาก สำหรับผู้ใช้ GitHub ต้องใช้เวลาเรียนรู้และตั้งค่าเซิร์ฟเวอร์ ง่าย สำหรับผู้ใช้ GitLab ค่อนข้างง่าย
ความยืดหยุ่น/ความสามารถในการปรับแต่ง สูง (YAML, Scripts, Custom Actions) สูงมาก (Groovy DSL, Plugins, Scripting) สูง (YAML, Docker, Scripts) สูง (YAML, Orbs, Docker)
การจัดการ Secrets Secrets ใน GitHub Repo/Environment/Org Credentials Plugin CI/CD Variables, Protected Variables Contexts, Project Environment Variables
ต้นทุน (Public Repo) ฟรีไม่จำกัด ฟรี (Open Source) ฟรี มี Free Tier
ต้นทุน (Private Repo) มี Free Tier รายเดือน, คิดตามนาทีที่ใช้ ฟรี (ต้องเสียค่า Infrastructure เอง) มี Free Tier รายเดือน, คิดตามนาทีที่ใช้ มี Free Tier รายเดือน, คิดตามนาทีที่ใช้
เหมาะสำหรับ ผู้ใช้ GitHub, โปรเจกต์ที่ต้องการความรวดเร็วในการตั้งค่าและ Scalability โปรเจกต์ขนาดใหญ่, องค์กรที่มี Legacy Systems, ต้องการความยืดหยุ่นสูงสุด ผู้ใช้ GitLab, โปรเจกต์ที่ต้องการ All-in-one DevOps Platform โปรเจกต์ที่ต้องการความเร็ว, ความน่าเชื่อถือ, และการใช้งานที่ง่าย

สรุปการเปรียบเทียบ:

  • GitHub Actions: โดดเด่นเรื่องการรวมกับ GitHub ได้อย่างลงตัว, ใช้งานง่าย, และมี Marketplace ที่กว้างขวาง เหมาะสำหรับทีมที่ใช้ GitHub เป็นหลักและต้องการเริ่มต้น CI/CD ได้อย่างรวดเร็ว
  • Jenkins: เป็นตัวเลือกที่ยืดหยุ่นและทรงพลังที่สุด เหมาะสำหรับองค์กรขนาดใหญ่ที่มีความต้องการเฉพาะเจาะจง หรือมี Legacy Systems แต่ก็มาพร้อมกับความซับซ้อนในการตั้งค่าและดูแลรักษา
  • GitLab CI/CD: เป็นส่วนหนึ่งของ GitLab ecosystem ที่ครบวงจร เหมาะสำหรับทีมที่ใช้ GitLab เป็นหลัก และต้องการเครื่องมือ DevOps แบบ All-in-one
  • CircleCI: มีชื่อเสียงด้านความเร็วและความน่าเชื่อถือ ใช้งานง่ายและมี Orbs คล้ายกับ Actions เหมาะสำหรับทีมที่ต้องการ CI/CD ที่รวดเร็วและมีประสิทธิภาพ

การเลือกเครื่องมือ CI/CD ขึ้นอยู่กับความต้องการเฉพาะของโปรเจกต์, ทีม, และงบประมาณเป็นหลักครับ แต่สำหรับผู้ที่ใช้ GitHub อยู่แล้ว GitHub Actions ถือเป็นตัวเลือกที่ไม่ควรมองข้ามเลยครับ

8. การแก้ไขปัญหาที่พบบ่อยใน GitHub Actions CI/CD

แม้ว่า GitHub Actions จะใช้งานง่าย แต่ก็อาจพบปัญหาได้บ้าง นี่คือปัญหาที่พบบ่อยพร้อมแนวทางแก้ไขครับ

  1. Workflow Fail โดยไม่มีเหตุผลชัดเจน:
    • ตรวจสอบ Log อย่างละเอียด: สิ่งแรกที่ควรทำคือคลิกที่ Workflow run ที่ล้มเหลว แล้วเจาะลึกไปที่ Job และ Step ที่ล้มเหลว อ่านข้อความ error ใน Log อย่างละเอียดครับ Log มักจะบอกสาเหตุที่ชัดเจนที่สุด
    • เพิ่ม Verbosity: บางครั้งการรันคำสั่งด้วย -v หรือ --debug อาจช่วยให้ได้ข้อมูลเพิ่มเติม
    • รัน Locally: ลองรันคำสั่งที่ล้มเหลวบนเครื่องของคุณเอง (ถ้าทำได้) เพื่อจำลองสภาพแวดล้อมและดูว่าเกิดอะไรขึ้น
  2. Permission Denied:
    • สิทธิ์ของ GITHUB_TOKEN: หาก Workflow ต้องการโต้ตอบกับ GitHub API (เช่น การสร้าง Release, การคอมมิต) ตรวจสอบว่า GITHUB_TOKEN มีสิทธิ์เพียงพอใน permissions block ของ Workflow
    • สิทธิ์ของ Runner: หากใช้ Self-hosted runner ตรวจสอบว่า Runner มีสิทธิ์ในการเข้าถึงไฟล์หรือทรัพยากรที่จำเป็น
  3. Secrets ไม่ทำงาน:
    • ชื่อ Secret ไม่ถูกต้อง: ตรวจสอบว่าชื่อ Secret ที่ใช้ใน Workflow (${{ secrets.MY_SECRET }}) ตรงกับชื่อ Secret ที่ตั้งค่าไว้ใน Repository ทุกประการ (case-sensitive)
    • ไม่ได้กำหนด Secret: ตรวจสอบว่าได้กำหนด Secret ใน Settings -> Secrets and variables -> Actions ของ Repository แล้ว
    • เข้าถึงผิด Scope: Secrets ที่กำหนดใน Environment จะใช้ได้เฉพาะใน Job ที่รันใน Environment นั้นๆ เท่านั้น
  4. Dependency Installation Failed:
    • เวอร์ชันไม่ตรงกัน: ตรวจสอบว่าเวอร์ชันของภาษา (Node.js, Python, Java) หรือ Package Manager (npm, yarn, pip) ที่ระบุใน Workflow ตรงกับสิ่งที่โปรเจกต์ต้องการ
    • Registry Issue: หากใช้ Private Registry ตรวจสอบว่ามีการ Authenticate อย่างถูกต้อง
    • Cache Corrupted: หากใช้ Cache ลองลบ Cache แล้วรันใหม่
  5. Workflow รันช้า:
    • ไม่ได้ใช้ Cache: พิจารณาใช้ actions/cache สำหรับ Dependencies เพื่อลดเวลาในการติดตั้ง
    • Runner ช้า: หากใช้ GitHub-hosted runners ลองตรวจสอบว่า Job ของคุณใช้ทรัพยากรมากเกินไปหรือไม่ หากเป็น Self-hosted runner ตรวจสอบประสิทธิภาพของเครื่อง
    • Parallel Jobs: หากเป็นไปได้ ให้แบ่ง Job ที่ไม่ขึ้นต่อกันให้รันแบบขนาน (parallel)
  6. Workflow ไม่ถูก Trigger:
    • Event ผิด: ตรวจสอบว่า on: block กำหนด Event และ Branch ที่ถูกต้อง
    • Path/Filter ไม่ถูกต้อง: หากมีการใช้ paths หรือ branches filters ใน on: block ตรวจสอบว่าเงื่อนไขตรงกับการเปลี่ยนแปลงโค้ดของคุณ
    • ไฟล์ Workflow ไม่ถูกคอมมิต: ตรวจสอบว่าไฟล์ .github/workflows/your-workflow.yml ถูกคอมมิตและ push ไปยัง Repository แล้ว

สิ่งสำคัญที่สุดคือการทำความเข้าใจข้อความ Error ที่ปรากฏใน Log ของ GitHub Actions และใช้ความรู้เกี่ยวกับส่วนประกอบของ Workflow เพื่อแก้ไขปัญหาอย่างเป็นระบบครับ

9. แนวทางปฏิบัติที่ดีที่สุดสำหรับ CI/CD ด้วย GitHub Actions

เพื่อให้ CI/CD Pipeline ของคุณมีประสิทธิภาพ ปลอดภัย และดูแลรักษาง่าย ลองนำแนวทางปฏิบัติเหล่านี้ไปใช้ครับ

  1. Keep Workflows Modular and Focused:
    • แบ่ง Workflow ออกเป็น Jobs ย่อยๆ ที่มีหน้าที่เฉพาะเจาะจง (เช่น build, test, deploy)
    • หาก Workflow มีขนาดใหญ่และซับซ้อน ลองใช้ Reusable Workflows เพื่อลดความซ้ำซ้อน
  2. Use Specific Action Versions:
    • ระบุเวอร์ชันของ Actions ที่ใช้ให้ชัดเจน (เช่น actions/checkout@v4 แทนที่จะเป็น actions/checkout@main หรือ actions/checkout เฉยๆ) เพื่อความเสถียรและป้องกันการเปลี่ยนแปลงที่ไม่คาดคิด
  3. Leverage Secrets for Sensitive Data:
    • ไม่ควร hardcode API Keys, Tokens, หรือรหัสผ่านลงในไฟล์ Workflow ใช้ GitHub Secrets เสมอ
    • จำกัดสิทธิ์การเข้าถึง Secrets ให้เฉพาะ Job หรือ Environment ที่จำเป็นเท่านั้น
  4. Use Caching for Dependencies:
    • ใช้ actions/cache เพื่อแคช Dependencies (node_modules, .m2, etc.) เพื่อลดเวลาในการรัน Workflow
  5. Implement Status Checks for Pull Requests:
    • กำหนดให้ CI Workflow เป็น “Required status check” ใน Branch Protection Rules เพื่อให้มั่นใจว่าทุก Pull Request ต้องผ่าน CI ก่อนจึงจะ Merge ได้
  6. Monitor Workflow Runs:
    • ตรวจสอบสถานะของ Workflow run เป็นประจำในแท็บ “Actions”
    • ตั้งค่าการแจ้งเตือน (Notifications) สำหรับ Workflow ที่ล้มเหลว
  7. Test Workflows Locally (Optional but Recommended):
    • ใช้เครื่องมือเช่น act (https://github.com/nektos/act) เพื่อรัน GitHub Actions Workflows บนเครื่อง Local ของคุณก่อนที่จะ Push ขึ้นไปบน GitHub เพื่อประหยัดเวลาและโควต้า
  8. Document Your Pipelines:
    • เขียนคำอธิบายหรือ comment ในไฟล์ YAML เพื่ออธิบายวัตถุประสงค์ของแต่ละ Job หรือ Step
    • มีเอกสารประกอบสำหรับ Pipeline ที่สำคัญ โดยเฉพาะอย่างยิ่งสำหรับกระบวนการ Deploy
  9. Use Environments for Staging/Production:
    • แยก Environment สำหรับ Staging และ Production ออกจากกัน เพื่อให้สามารถทดสอบได้อย่างเต็มที่ก่อนจะ Deploy สู่ Production
    • เพิ่ม Approval Gates สำหรับ Environment Production เพื่อควบคุมการ Deploy
  10. Follow Least Privilege Principle:
    • จำกัดสิทธิ์ของ GITHUB_TOKEN ให้แคบที่สุดเท่าที่ Workflow ต้องการ โดยใช้ permissions block

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

เราได้รวบรวมคำถามที่พบบ่อยเกี่ยวกับการใช้ GitHub Actions สำหรับ CI/CD มาไว้ที่นี่ครับ

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

A1: GitHub Actions ให้บริการฟรีสำหรับ Repository สาธารณะ (Public Repository) โดยไม่มีข้อจำกัดในการใช้งานครับ สำหรับ Private Repository จะมีโควต้าฟรีให้ใช้ในแต่ละเดือน (เช่น 2,000 นาที/เดือน สำหรับบัญชี Free) หากใช้งานเกินโควต้าจะมีการคิดค่าใช้จ่ายตามนาทีที่ใช้งานครับ

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

Siam2R.com — Portfolio งาน IT · XM Signal — Free Forex EA Download

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