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

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

March 15, 2026
1 View

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

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

สารบัญ

บทนำ: ทำไม CI/CD และ GitHub Actions ถึงสำคัญในโลกยุคใหม่

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

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

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

อะไรคือ CI/CD Pipeline?

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

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

Continuous Integration (CI) คือแนวทางปฏิบัติที่นักพัฒนาจะผสานรวมโค้ดที่พัฒนาเสร็จแล้วเข้าสู่ Repository หลัก (เช่น main หรือ master branch) บ่อยครั้ง ซึ่งอาจจะเป็นหลายครั้งต่อวันเลยก็ได้ครับ เมื่อมีการผสานรวมโค้ด ระบบ CI จะทำการ Build และ Run ชุดการทดสอบอัตโนมัติ (Automated Tests) เพื่อตรวจสอบว่าการเปลี่ยนแปลงที่เกิดขึ้นไม่ได้ทำให้เกิดข้อผิดพลาดหรือทำให้ส่วนอื่นๆ ของระบบเสียหาย

ประโยชน์หลักของ CI คือ:

  • ตรวจจับข้อผิดพลาดได้เร็ว: การรวมโค้ดบ่อยๆ และการทดสอบอัตโนมัติ ช่วยให้พบข้อผิดพลาดหรือ Bug ได้ตั้งแต่เนิ่นๆ ทำให้แก้ไขได้ง่ายและใช้เวลาน้อยลง
  • ลดปัญหาการรวมโค้ด: เมื่อโค้ดถูกรวมบ่อยๆ ความขัดแย้ง (Merge Conflicts) จะเกิดขึ้นน้อยลง และแก้ไขได้ง่ายขึ้น
  • เพิ่มความมั่นใจในโค้ด: ทีมพัฒนามั่นใจได้ว่าโค้ดที่อยู่บน Repository หลักนั้นสามารถทำงานได้

Continuous Delivery (CD) คืออะไร?

Continuous Delivery (CD) คือส่วนขยายของ CI ครับ หลังจากที่โค้ดผ่านกระบวนการ CI (Build และ Test) เรียบร้อยแล้ว ระบบ CD จะนำโค้ดที่ผ่านการทดสอบนั้นไปเตรียมพร้อมสำหรับการ Deploy โดยอัตโนมัติ ซึ่งหมายความว่าโค้ดของคุณจะอยู่ในสถานะที่ “พร้อมส่งมอบ” (Release-ready) ได้ตลอดเวลา แต่การ Deploy ไปยัง Production นั้นยังคงต้องมีการตัดสินใจและอนุมัติจากมนุษย์อยู่ครับ

ประโยชน์หลักของ CD คือ:

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

Continuous Deployment (CDP) คืออะไร?

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

ข้อควรพิจารณาสำหรับ CDP:

  • ต้องการการทดสอบที่ครอบคลุม: ต้องมีการทดสอบอัตโนมัติที่แข็งแกร่งและครอบคลุมทุกกรณีอย่างแท้จริง
  • การมอนิเตอร์ที่เข้มข้น: ต้องมีระบบมอนิเตอร์ที่ดีเพื่อตรวจจับปัญหาที่อาจเกิดขึ้นหลังการ Deploy ทันที

สรุปง่ายๆ คือ CI คือการรวมและทดสอบโค้ด, CD (Delivery) คือการเตรียมโค้ดให้พร้อม Deploy แต่ยังต้องมีคนอนุมัติ, ส่วน CD (Deployment) คือการ Deploy อัตโนมัติทั้งหมดครับ

ประโยชน์ของ CI/CD Pipeline

การนำ CI/CD Pipeline มาใช้ในการพัฒนาซอฟต์แวร์นำมาซึ่งประโยชน์มากมาย ดังนี้ครับ:

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

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

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

GitHub Actions คืออะไร?

GitHub Actions คือแพลตฟอร์มสำหรับระบบ Automation และ CI/CD ที่ built-in มากับ GitHub โดยตรงครับ มันช่วยให้คุณสามารถสร้าง workflow หรือชุดคำสั่งอัตโนมัติ ที่จะทำงานเมื่อมี event บางอย่างเกิดขึ้นใน Repository ของคุณ เช่น การ Push โค้ด, การสร้าง Pull Request, การออก Release ใหม่, หรือแม้แต่การตั้งเวลาให้ทำงานเป็นประจำ

ด้วย GitHub Actions คุณสามารถ Automate ได้ทุกอย่าง ตั้งแต่การ Build, Test, และ Deploy โค้ด ไปจนถึงการจัดการ Pull Request, การติด Tag, หรือการแจ้งเตือนต่างๆ ครับ

ทำไมต้องเลือก GitHub Actions?

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

  • ผสานรวมกับ GitHub อย่างสมบูรณ์: เนื่องจากเป็นส่วนหนึ่งของ GitHub ทำให้การตั้งค่าและการใช้งานเป็นไปอย่างราบรื่น ไม่ต้องเชื่อมต่อกับบริการภายนอกให้ยุ่งยาก
  • ใช้งานง่าย: Workflow ถูกกำหนดด้วยไฟล์ YAML ที่อ่านและเขียนได้ง่าย
  • มี Marketplace ขนาดใหญ่: มี Actions สำเร็จรูปมากมายที่พัฒนาโดย GitHub และชุมชน ทำให้คุณไม่ต้องเขียนทุกอย่างเอง
  • รองรับภาษาและแพลตฟอร์มที่หลากหลาย: ไม่ว่าโปรเจกต์ของคุณจะใช้ภาษาอะไร (Node.js, Python, Java, Go, .NET) หรือ Deploy ไปที่ไหน (AWS, Azure, GCP, Heroku) GitHub Actions ก็รองรับทั้งหมดครับ
  • ฟรีสำหรับ Public Repository: และมีโควต้าฟรีจำนวนหนึ่งสำหรับ Private Repository ซึ่งเพียงพอสำหรับโปรเจกต์ขนาดเล็กถึงกลางจำนวนมาก
  • ความยืดหยุ่นสูง: สามารถกำหนด Logic ของ Workflow ได้อย่างละเอียด มีเงื่อนไข (Conditional Logic), Matrix Strategies, และ Reusable Workflows
  • รองรับ Self-Hosted Runners: สำหรับกรณีที่ต้องการสภาพแวดล้อมที่กำหนดเอง หรือต้องการรันบน Hardware เฉพาะ

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

เพื่อให้เข้าใจการทำงานของ GitHub Actions เรามาดูส่วนประกอบหลักๆ กันครับ

Workflow

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

Event

Event คือกิจกรรมที่เกิดขึ้นใน Repository ของคุณที่สามารถเรียกให้ Workflow ทำงานได้ ตัวอย่างเช่น:

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

Job

Job คือชุดของ Step ที่จะถูก Execute บน Runner เดียวกันครับ Workflow หนึ่งสามารถมีได้หลาย Job และ Job สามารถรันแบบขนานกันได้ หรือจะกำหนดให้รันตามลำดับ (Sequential) โดยขึ้นอยู่กับผลลัพธ์ของ Job ก่อนหน้าก็ได้

Step

Step คือชุดของคำสั่งหรือ Action ที่จะถูก Execute ตามลำดับภายใน Job หนึ่งๆ ครับ แต่ละ Step จะทำหน้าที่เฉพาะอย่าง เช่น การ Checkout โค้ด, การติดตั้ง Dependencies, การรันคำสั่ง Shell, หรือการเรียกใช้ Action สำเร็จรูป

Action

Action คือหน่วยย่อยที่สุดของ Task ที่สามารถนำมาใช้ซ้ำได้ครับ มันอาจจะเป็น Script สั้นๆ หรือ Application ที่ซับซ้อนก็ได้ Action สามารถสร้างขึ้นเอง หรือเลือกใช้จาก GitHub Marketplace ที่มีอยู่มากมายครับ การใช้ Action ช่วยให้เราไม่ต้องเขียนโค้ดซ้ำๆ สำหรับ Task ทั่วไป

ตัวอย่าง Action:

  • actions/checkout@v4: สำหรับ Checkout โค้ดจาก Repository
  • actions/setup-node@v4: สำหรับตั้งค่า Node.js Environment
  • peter-evans/create-pull-request@v6: สำหรับสร้าง Pull Request

Runner

Runner คือ Server ที่รัน Job ใน Workflow ของคุณครับ GitHub Actions มี Runner ให้เลือกใช้ 2 ประเภทหลักๆ:

  • GitHub-hosted Runners: เป็น Server ที่ GitHub จัดเตรียมไว้ให้ โดยมี OS ให้เลือกหลากหลาย (Ubuntu, Windows, macOS) และมี Software ที่จำเป็นติดตั้งไว้ล่วงหน้าแล้ว สะดวกสบายและเหมาะสำหรับโปรเจกต์ส่วนใหญ่
  • Self-hosted Runners: เป็น Server ที่คุณติดตั้งและจัดการเอง ซึ่งอาจจะเป็น Server ในองค์กรของคุณ หรือ VM บน Cloud ก็ได้ครับ เหมาะสำหรับกรณีที่ต้องการ Hardware เฉพาะ, OS ที่ไม่รองรับโดย GitHub, หรือต้องการควบคุมสภาพแวดล้อมการรันอย่างเต็มที่

การสร้าง CI Pipeline ด้วย GitHub Actions (ตัวอย่างที่ 1: Node.js CI)

เรามาเริ่มต้นสร้าง CI Pipeline แรกของเราด้วย GitHub Actions กันครับ ในตัวอย่างนี้ เราจะสร้าง Workflow สำหรับโปรเจกต์ Node.js ที่จะทำการติดตั้ง Dependencies และรันชุดการทดสอบ (Tests) ทุกครั้งที่มีการ Push โค้ดไปยัง main branch หรือมีการสร้าง Pull Request ครับ

โครงสร้างไฟล์ Workflow (.yml)

ไฟล์ Workflow ของ GitHub Actions จะต้องอยู่ในไดเรกทอรี .github/workflows/ ภายใน Repository ของคุณครับ ชื่อไฟล์สามารถเป็นอะไรก็ได้ที่คุณต้องการ แต่ต้องลงท้ายด้วย .yml หรือ .yaml เช่น .github/workflows/nodejs-ci.yml

อธิบายแต่ละส่วนของ Workflow

ก่อนที่เราจะไปดูตัวอย่างโค้ด เรามาทำความเข้าใจโครงสร้างหลักของไฟล์ YAML สำหรับ Workflow กันก่อนครับ

name: Node.js CI

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20.x'
    - name: Install dependencies
      run: npm ci
    - name: Run tests
      run: npm test
  • name: ชื่อของ Workflow ที่จะแสดงใน GitHub UI (เป็น Optional)
  • on: กำหนด Event ที่จะเรียก Workflow นี้ให้ทำงาน ในที่นี้คือเมื่อมีการ push หรือ pull_request ไปยัง main branch
  • jobs: ส่วนที่ระบุ Job ต่างๆ ที่จะรัน
  • build: ชื่อของ Job (สามารถเป็นชื่ออะไรก็ได้)
  • runs-on: ระบุประเภทของ Runner ที่จะใช้ ในที่นี้คือ ubuntu-latest (GitHub-hosted Runner)
  • steps: รายการของ Step ที่จะถูก Execute ภายใน Job นี้
  • uses: ใช้สำหรับเรียก Action สำเร็จรูป
  • name: ชื่อของ Step ที่จะแสดงใน GitHub UI
  • run: ใช้สำหรับรันคำสั่ง Shell
  • with: ใช้สำหรับส่ง Parameter ไปยัง Action นั้นๆ

ตัวอย่าง Workflow: Build และ Test โปรเจกต์ Node.js

สมมติว่าคุณมีโปรเจกต์ Node.js ที่มีไฟล์ package.json และมี Script สำหรับ Test (เช่น "test": "jest") อยู่แล้ว นี่คือไฟล์ nodejs-ci.yml ที่คุณสามารถนำไปใช้งานได้ครับ

name: Node.js CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]
  workflow_dispatch: # อนุญาตให้รัน Workflow ด้วยตนเอง

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

    strategy:
      matrix:
        node-version: [18.x, 20.x] # ทดสอบกับ Node.js หลายเวอร์ชัน

    steps:
    - name: Checkout repository code
      uses: actions/checkout@v4 # Action สำหรับ Checkout โค้ดจาก GitHub Repository

    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4 # Action สำหรับติดตั้ง Node.js
      with:
        node-version: ${{ matrix.node-version }} # ใช้เวอร์ชัน Node.js ตามที่กำหนดใน matrix
        cache: 'npm' # เปิดใช้งานการ Cache สำหรับ npm dependencies เพื่อความเร็ว

    - name: Install dependencies
      run: npm ci # ติดตั้ง dependencies (npm ci จะใช้ package-lock.json เพื่อให้มั่นใจถึงเวอร์ชันที่แน่นอน)

    - name: Run tests
      run: npm test # รันชุดการทดสอบที่กำหนดไว้ใน package.json script

    - name: Build project (if applicable)
      run: npm run build # รันคำสั่ง build เช่น 'npm run build' หากโปรเจกต์ของคุณต้องการ (เช่น React, Vue)
      if: success() # รันขั้นตอนนี้ก็ต่อเมื่อขั้นตอนก่อนหน้าสำเร็จเท่านั้น

    - name: Upload coverage reports (optional)
      uses: actions/upload-artifact@v4 # Action สำหรับอัปโหลดไฟล์ (เช่น Coverage Reports)
      with:
        name: coverage-report-${{ matrix.node-version }}
        path: coverage/lcov.info # สมมติว่า coverage report อยู่ที่นี่
      if: always() # อัปโหลดเสมอ ไม่ว่าการทดสอบจะสำเร็จหรือไม่ก็ตาม

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

  • on: Workflow นี้จะทำงานเมื่อมีการ Push โค้ดไปยัง main หรือ develop branch, มีการสร้าง/อัปเดต Pull Request ที่มีเป้าหมายเป็น main หรือ develop, หรือเมื่อคุณสั่งรันด้วยตนเองผ่านปุ่ม “Run workflow” ใน GitHub UI (workflow_dispatch)
  • strategy.matrix.node-version: [18.x, 20.x]: นี่คือคุณสมบัติที่เรียกว่า Matrix Strategy ครับ มันจะทำให้ Job build_and_test ถูกรันสองครั้ง โดยแต่ละครั้งจะใช้ Node.js เวอร์ชัน 18.x และ 20.x ตามลำดับ เพื่อให้คุณมั่นใจว่าแอปพลิเคชันของคุณทำงานได้ดีกับ Node.js หลายเวอร์ชัน
  • uses: actions/checkout@v4: Action นี้มีความสำคัญมาก เพราะมันจะดึงโค้ดจาก Repository ของคุณมาไว้ใน Runner เพื่อให้ Job สามารถเข้าถึงไฟล์โปรเจกต์ได้
  • uses: actions/setup-node@v4: Action นี้จะติดตั้ง Node.js เวอร์ชันที่ระบุ (ในที่นี้คือ ${{ matrix.node-version }} ซึ่งจะถูกแทนที่ด้วย 18.x หรือ 20.x) และยังสามารถตั้งค่า Cache สำหรับ npm เพื่อให้การติดตั้ง Dependencies ครั้งถัดไปเร็วขึ้น
  • run: npm ci: คำสั่งนี้จะติดตั้ง Dependencies ทั้งหมดที่ระบุใน package-lock.json (หรือ yarn.lock) การใช้ npm ci จะดีกว่า npm install ในสภาพแวดล้อม CI เพราะมันจะรับประกันว่า Dependencies ที่ติดตั้งจะตรงกับที่ระบุในไฟล์ Lock เสมอ
  • run: npm test: คำสั่งนี้จะรัน Script test ที่คุณกำหนดไว้ใน package.json ของคุณ
  • if: success(): เป็นเงื่อนไขที่บอกว่า Step นี้จะทำงานก็ต่อเมื่อ Step ก่อนหน้าทั้งหมดสำเร็จเท่านั้น
  • uses: actions/upload-artifact@v4: เป็น Action ที่ช่วยให้คุณสามารถอัปโหลดไฟล์หรือโฟลเดอร์ที่สร้างขึ้นระหว่าง Workflow ไปเก็บไว้เป็น “Artifact” ได้ ซึ่งมีประโยชน์สำหรับการเก็บ Log, Test Report, หรือ Build Output ครับ คุณสามารถดาวน์โหลด Artifact เหล่านี้ได้จากหน้า Workflow Run ใน GitHub.

การตั้งค่า Environment Variables และ Secrets

บ่อยครั้งที่ Workflow ของคุณอาจต้องการเข้าถึงข้อมูลที่ละเอียดอ่อน เช่น API Key, Database Credentials หรือ Token ต่างๆ GitHub Actions มีวิธีจัดการข้อมูลเหล่านี้อย่างปลอดภัยผ่าน Secrets ครับ

  • Environment Variables:

    คุณสามารถกำหนด Environment Variables ได้ทั้งในระดับ Workflow, Job, หรือ Step โดยใช้คีย์ env:

    jobs:
  my_job:
    runs-on: ubuntu-latest
    env: # กำหนดในระดับ Job
      MY_APP_ENV: production
    steps:
    - name: My Step
      env: # กำหนดในระดับ Step
        ANOTHER_VAR: some_value
      run: echo "Environment is $MY_APP_ENV and $ANOTHER_VAR"
  • Secrets:

    สำหรับข้อมูลที่ละเอียดอ่อน เช่น API Key คุณไม่ควร hardcode ลงในไฟล์ Workflow ครับ ให้ใช้ GitHub Secrets แทน

    วิธีตั้งค่า Secret:

    1. ไปที่ Repository ของคุณบน GitHub.com
    2. คลิกที่แท็บ Settings
    3. ในเมนูด้านซ้าย เลือก Secrets and variables > Actions
    4. คลิก New repository secret
    5. ตั้งชื่อ Secret (เช่น MY_API_KEY) และใส่ค่าของ Secret นั้น

    วิธีใช้งาน Secret ใน Workflow:

    คุณสามารถเข้าถึง Secret ได้ผ่าน Context secrets ดังนี้:

    jobs:
  my_job:
    runs-on: ubuntu-latest
    steps:
    - name: Use a secret
      run: echo "My API Key is masked: ${{ secrets.MY_API_KEY }}"
      env:
        SECRET_KEY: ${{ secrets.MY_API_KEY }} # ส่ง Secret เข้าไปเป็น Environment Variable

    GitHub จะทำการปกปิดค่าของ Secret ใน Log ของ Workflow โดยอัตโนมัติ เพื่อป้องกันการรั่วไหลของข้อมูลครับ

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

การสร้าง CD Pipeline ด้วย GitHub Actions (ตัวอย่างที่ 2: Deploy Static Website ไปยัง GitHub Pages)

หลังจากที่เราสามารถ Build และ Test โค้ดได้แล้ว ขั้นตอนต่อไปคือการ Deploy ครับ ในตัวอย่างนี้เราจะสร้าง CD Pipeline ที่จะ Deploy Static Website (เช่น เว็บไซต์ที่สร้างด้วย React, Vue, หรือ Jekyll) ไปยัง GitHub Pages ซึ่งเป็นบริการโฮสติ้งฟรีจาก GitHub ครับ

หลักการ Deploy อัตโนมัติ

การ Deploy อัตโนมัติด้วย GitHub Actions มักจะเกี่ยวข้องกับขั้นตอนหลักๆ ดังนี้ครับ:

  1. Checkout โค้ด: ดึง Source Code ล่าสุด
  2. Build Artifacts: ทำการ Build โปรเจกต์ให้ได้ Output ที่พร้อม Deploy (เช่น ไฟล์ HTML, CSS, JS ที่ถูก Optimize แล้ว)
  3. Authentication: เข้าสู่ระบบของแพลตฟอร์มปลายทาง (เช่น AWS, Azure, GCP, GitHub Pages)
  4. Deploy: อัปโหลด Artifacts ไปยังแพลตฟอร์มปลายทาง
  5. Clean up (Optional): ลบไฟล์ที่ไม่จำเป็น หรือ Clear Cache

ตัวอย่าง Workflow: Deploy Static Site ไปยัง GitHub Pages

ในตัวอย่างนี้ เราจะใช้ Action peaceiris/actions-gh-pages@v3 ซึ่งเป็น Action ยอดนิยมสำหรับ Deploy ไปยัง GitHub Pages ครับ

name: Deploy Static Site to GitHub Pages

on:
  push:
    branches: [ main ] # Trigger เมื่อมีการ push ไปที่ main branch

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository code
      uses: actions/checkout@v4
      with:
        # จำเป็นต้องใช้ Personal Access Token (PAT) หาก Repository เป็น Private
        # หรือถ้า GitHub Pages ต้องการสิทธิ์ในการเขียน
        # token: ${{ secrets.GITHUB_TOKEN }} # GITHUB_TOKEN มีสิทธิ์ใน Repository ปัจจุบันอยู่แล้ว

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20.x'

    - name: Install dependencies
      run: npm ci

    - name: Build static site
      run: npm run build # สมมติว่าคำสั่ง build ของคุณสร้างไฟล์ไว้ในโฟลเดอร์ 'dist' หรือ 'build'

    - name: Deploy to GitHub Pages
      uses: peaceiris/actions-gh-pages@v3
      if: github.ref == 'refs/heads/main' # รันขั้นตอนนี้เฉพาะเมื่อมีการ push ไปที่ main branch เท่านั้น
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }} # ใช้ GITHUB_TOKEN ที่ GitHub สร้างให้โดยอัตโนมัติ
        publish_dir: ./dist # ระบุโฟลเดอร์ที่เก็บไฟล์ Build ของคุณ (เช่น 'dist' หรือ 'build')
        # publish_branch: gh-pages # (Optional) กำหนด branch สำหรับ GitHub Pages, ค่าเริ่มต้นคือ gh-pages

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

  • github_token: ${{ secrets.GITHUB_TOKEN }}: GITHUB_TOKEN เป็น Secret พิเศษที่ GitHub สร้างให้โดยอัตโนมัติสำหรับทุก Workflow Run ครับ มันมีสิทธิ์ในการเขียนและอ่านใน Repository ปัจจุบัน และมักจะเพียงพอสำหรับการ Deploy ไปยัง GitHub Pages (หากไม่ได้มีการตั้งค่าสิทธิ์ที่ซับซ้อน)
  • publish_dir: ./dist: นี่คือ Path ไปยังโฟลเดอร์ที่เก็บไฟล์ Static Website ของคุณหลังจากที่ Build เสร็จแล้ว คุณต้องแน่ใจว่าได้ระบุ Path ที่ถูกต้องตามโครงสร้างโปรเจกต์ของคุณครับ (เช่น React มักจะ Build ไปที่ build, Vue ไปที่ dist)
  • if: github.ref == 'refs/heads/main': เป็นเงื่อนไขที่สำคัญครับ เราต้องการ Deploy ไปยัง GitHub Pages ก็ต่อเมื่อมีการ Push โค้ดไปยัง main branch เท่านั้น เพื่อป้องกันการ Deploy จาก branch อื่นๆ โดยไม่ตั้งใจ

การตั้งค่า GitHub Pages ใน Repository:

หลังจากที่คุณมี Workflow ข้างต้นแล้ว คุณจะต้องไปเปิดใช้งาน GitHub Pages ใน Settings ของ Repository ด้วยครับ

  1. ไปที่ Repository ของคุณบน GitHub.com
  2. คลิกที่แท็บ Settings
  3. ในเมนูด้านซ้าย เลือก Pages
  4. ในส่วน “Build and deployment”, เลือก Deploy from a branch และเลือก Branch ที่คุณต้องการให้เป็น Source (เช่น gh-pages หรือ main พร้อมโฟลเดอร์ /docs หรือ /root)
  5. บันทึกการเปลี่ยนแปลง

เมื่อ Workflow ทำงานสำเร็จ GitHub Pages ของคุณก็จะถูกอัปเดตโดยอัตโนมัติครับ

การ Deploy ไปยัง Cloud Providers (AWS S3, Azure Blob, Google Cloud Storage)

การ Deploy ไปยัง Cloud Providers ต่างๆ ก็มีหลักการคล้ายกันครับ คือการ Build โปรเจกต์ให้เป็น Artifacts แล้วทำการอัปโหลดไปยังบริการจัดเก็บ Object Storage (เช่น AWS S3, Azure Blob Storage, Google Cloud Storage) หรือไปยังบริการ Hosting อื่นๆ

  • แนวคิดและหลักการ:

    โดยทั่วไปแล้ว คุณจะต้อง:

    1. ติดตั้ง CLI Tools: เช่น AWS CLI, Azure CLI, gcloud CLI ใน Runner
    2. Authentication: กำหนด Credentials (เช่น Access Key, Secret Key, Service Principal) เป็น GitHub Secrets
    3. อัปโหลด: ใช้คำสั่ง CLI หรือ Action สำเร็จรูปในการอัปโหลดไฟล์ที่ Build แล้วไปยัง Object Storage หรือบริการที่เกี่ยวข้อง
    4. Invalidate CDN Cache (ถ้ามี): หากคุณใช้ CDN (เช่น Amazon CloudFront, Azure CDN) คุณอาจจะต้องสั่ง Invalidate Cache เพื่อให้ผู้ใช้งานได้รับเวอร์ชันล่าสุดทันที
  • การใช้ Marketplace Actions:

    ข้อดีของ GitHub Actions คือมี Actions สำเร็จรูปสำหรับ Cloud Providers ยอดนิยมอยู่แล้วมากมาย ทำให้การ Deploy เป็นเรื่องง่ายขึ้นมากครับ ตัวอย่างเช่น:

    • สำหรับ AWS S3/CloudFront: aws-actions/configure-aws-credentials@v4 ตามด้วย aws-actions/amazon-s3-deploy@v1 และ aws-actions/cloudfront-invalidate-action@v1
    • สำหรับ Azure: azure/login@v1 ตามด้วย azure/webapps-deploy@v2 หรือ azure/CLI@v1
    • สำหรับ Google Cloud: google-github-actions/auth@v2 ตามด้วย google-github-actions/upload-cloud-storage@v2 หรือ google-github-actions/deploy-cloudrun@v2

    การใช้ Actions เหล่านี้จะช่วยลดความซับซ้อนในการเขียน Script และรับประกันว่าการ Deploy จะเป็นไปตาม Best Practices ของแต่ละ Cloud ครับ

ศึกษาเพิ่มเติมเกี่ยวกับการ Deploy ไปยัง Cloud ด้วย GitHub Actions

เทคนิคและ Best Practices สำหรับ GitHub Actions

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

การใช้ Reusable Workflows

เมื่อโปรเจกต์ของคุณมีขนาดใหญ่ขึ้น หรือคุณมีหลายโปรเจกต์ที่ใช้ Workflow คล้ายๆ กัน การเขียน Workflow ซ้ำๆ จะเป็นเรื่องที่น่าเบื่อและยากต่อการบำรุงรักษาครับ GitHub Actions มีฟีเจอร์ที่เรียกว่า Reusable Workflows ที่ช่วยให้คุณสามารถสร้าง Workflow ที่สามารถนำกลับมาใช้ซ้ำได้เหมือนเป็นฟังก์ชัน

ตัวอย่าง: คุณสามารถสร้าง Workflow สำหรับ Build และ Test Node.js ที่สามารถเรียกใช้จาก Workflow อื่นๆ ได้

.github/workflows/reusable-build-test.yml

name: Reusable Node.js Build and Test

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
        description: 'Node.js version to use'
    outputs:
      build-status:
        description: 'Status of the build job'
        value: ${{ jobs.build.outputs.status }}

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      status: ${{ job.status }}
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}
    - run: npm ci
    - run: npm test

และเรียกใช้จาก Workflow อื่นๆ:

name: Main App CI

on:
  push:
    branches: [ main ]

jobs:
  call-build-test:
    uses: ./.github/workflows/reusable-build-test.yml # เรียกใช้ Reusable Workflow
    with:
      node-version: '20.x'
    secrets:
      # ส่ง secrets ที่จำเป็นไปยัง reusable workflow หากมี
      # MY_SECRET: ${{ secrets.MY_SECRET }}

Reusable Workflows ช่วยให้คุณลดความซ้ำซ้อน ทำให้ Workflow บำรุงรักษาง่ายขึ้น และมั่นใจได้ถึงความสอดคล้องกัน

การจัดการ Secrets อย่างปลอดภัย

  • ใช้ GitHub Secrets เสมอ: ห้าม Hardcode ข้อมูลที่ละเอียดอ่อนในไฟล์ Workflow เด็ดขาด
  • จำกัดสิทธิ์ของ Secrets: กำหนด Secrets ให้เข้าถึงได้เฉพาะใน Repository, Environment หรือ Organization ที่จำเป็นเท่านั้น
  • ใช้ Environments: หากคุณมีสภาพแวดล้อมการ Deploy ที่แตกต่างกัน (เช่น Staging, Production) ให้ใช้ GitHub Environments เพื่อกำหนด Secrets และการอนุมัติการ Deploy ที่แตกต่างกัน
  • ใช้ OIDC: สำหรับการเชื่อมต่อกับ Cloud Providers ควรใช้ OpenID Connect (OIDC) แทนการใช้ Static Credentials (Access Key/Secret Key) เพื่อเพิ่มความปลอดภัย

การใช้ Environment Variables

ใช้ Environment Variables สำหรับการตั้งค่าที่ไม่ใช่ข้อมูลอ่อนไหว แต่มีการเปลี่ยนแปลงบ่อย หรือแตกต่างกันไปตามสภาพแวดล้อม เช่น ชื่อโปรเจกต์, โฟลเดอร์ Build Output, หรือ URL ของ API Test

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      BUILD_DIR: dist
      API_ENDPOINT_TEST: https://api.test.example.com
    steps:
    - name: Run build script
      run: npm run build --output-path $BUILD_DIR
    - name: Run API tests
      run: curl $API_ENDPOINT_TEST/health

การใช้ Matrix Strategies

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

การตรวจสอบสถานะ Workflow และ Debugging

  • ดู Workflow Runs: ไปที่แท็บ “Actions” ใน GitHub Repository ของคุณ เพื่อดูสถานะของ Workflow แต่ละครั้ง คุณจะเห็น Job และ Step ทั้งหมด รวมถึง Log ที่ละเอียด
  • ใช้ Logging ที่เหมาะสม: ทำให้ Script หรือคำสั่งของคุณมีการ Log Output ที่ชัดเจน เพื่อให้ง่ายต่อการ Debug
  • รัน Workflow ด้วยตนเอง (workflow_dispatch): หากคุณต้องการทดสอบการเปลี่ยนแปลงใน Workflow โดยไม่ต้องการ Push โค้ดไปยัง Branch หลัก คุณสามารถเพิ่ม workflow_dispatch: ในส่วน on: และรัน Workflow ด้วยตนเองได้
  • ใช้ debug mode: สำหรับ Actions บางตัว หรือ Runner สามารถเปิด debug mode เพื่อดูข้อมูลเพิ่มเติมใน Log ได้

การใช้ Self-Hosted Runners (เมื่อไหร่ที่ควรใช้)

แม้ว่า GitHub-hosted Runners จะสะดวกสบาย แต่ก็มีบางกรณีที่คุณอาจต้องพิจารณาใช้ Self-hosted Runners ครับ

  • ความต้องการ Hardware เฉพาะ: เช่น GPU สำหรับ Machine Learning, CPU หรือ RAM จำนวนมาก
  • OS หรือ Software ที่ไม่รองรับ: หากโปรเจกต์ของคุณต้องการ OS เวอร์ชันเฉพาะ หรือ Software ที่ GitHub-hosted Runners ไม่มี
  • การเข้าถึง Network ภายใน: หาก Workflow ของคุณต้องเข้าถึงทรัพยากรภายใน Private Network ขององค์กร (เช่น Database, Internal API)
  • ข้อจำกัดด้านความปลอดภัย/การกำกับดูแล: บางองค์กรอาจมีนโยบายที่ไม่ต้องการให้โค้ดรันบน Server สาธารณะ
  • ลดต้นทุน (ในบางกรณี): สำหรับการใช้งานที่หนักมาก การใช้ Self-hosted Runners อาจมีต้นทุนที่ถูกกว่าในระยะยาว (แต่ต้องแลกมาด้วยค่าบำรุงรักษา)

นี่คือตารางเปรียบเทียบระหว่าง GitHub-hosted Runners กับ Self-hosted Runners ครับ

คุณสมบัติ GitHub-hosted Runners Self-hosted Runners
การจัดการ GitHub จัดการทั้งหมด (OS, Software, Maintenance) คุณติดตั้งและจัดการเองทั้งหมด
ค่าใช้จ่าย คิดตามนาทีที่ใช้งาน (มีโควต้าฟรี) ฟรี แต่มีค่าใช้จ่าย Hardware/VM และค่าบำรุงรักษาของคุณเอง
สภาพแวดล้อม มาตรฐาน, มี OS และ Software ทั่วไปให้เลือก ปรับแต่งได้อย่างเต็มที่ (OS, Software, Hardware)
ความเร็ว/ประสิทธิภาพ รวดเร็วสำหรับงานทั่วไป, อาจมีข้อจำกัดด้าน Hardware สามารถปรับขนาด Hardware ให้ตรงกับความต้องการสูงสุดได้
การเข้าถึง Network เข้าถึง Public Internet เท่านั้น สามารถเข้าถึง Private Network ภายในองค์กรได้
ความปลอดภัย จัดการโดย GitHub, สภาพแวดล้อมใหม่ทุกครั้ง คุณต้องรับผิดชอบการรักษาความปลอดภัยของ Runner เอง
เหมาะสำหรับ โปรเจกต์ทั่วไป, Open Source, เริ่มต้นใช้งาน โปรเจกต์ที่มีความต้องการเฉพาะ, มีข้อจำกัดด้านความปลอดภัย/เครือข่ายภายใน

ความปลอดภัยใน CI/CD Pipeline ด้วย GitHub Actions

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

การควบคุมการเข้าถึง (Least Privilege)

  • จำกัดสิทธิ์ของ GITHUB_TOKEN: โดยค่าเริ่มต้น GITHUB_TOKEN มีสิทธิ์ค่อนข้างกว้างขวางใน Repository คุณสามารถจำกัดสิทธิ์ได้โดยการเพิ่ม permissions: block ใน Workflow ของคุณ เช่น permissions: contents: read หาก Workflow แค่ต้องการอ่านโค้ด หรือ permissions: id-token: write สำหรับ OIDC
  • จำกัดสิทธิ์ของ Secrets: กำหนดให้ Secrets เข้าถึงได้เฉพาะ Workflow หรือ Environment ที่จำเป็นเท่านั้น
  • ใช้ Environments: กำหนด Policy การอนุมัติสำหรับ Environments ที่ละเอียดอ่อน เช่น Production เพื่อให้มั่นใจว่ามีคนอนุมัติก่อนการ Deploy

การสแกนช่องโหว่ (Vulnerability Scanning)

รวมขั้นตอนการสแกนช่องโหว่เข้ากับ CI Pipeline ของคุณครับ

  • Dependency Scanning: ใช้เครื่องมือเช่น Dependabot (ใน GitHub), Snyk, หรือ Trivy เพื่อสแกนหาช่องโหว่ใน Library และ Dependencies ที่โปรเจกต์ของคุณใช้งาน
  • Static Application Security Testing (SAST): ใช้เครื่องมือ SAST เพื่อวิเคราะห์ Source Code และค้นหาช่องโหว่ที่อาจเกิดขึ้น (เช่น CodeQL ของ GitHub)
  • Dynamic Application Security Testing (DAST): สำหรับแอปพลิเคชันที่รันอยู่แล้ว DAST สามารถจำลองการโจมตีเพื่อค้นหาช่องโหว่ได้

การตรวจสอบโค้ด (Code Review)

แม้จะเป็นขั้นตอนนอกเหนือจาก Workflow โดยตรง แต่ Code Review ก็เป็นส่วนสำคัญในการป้องกันปัญหาด้านความปลอดภัยครับ การมีคนอื่นช่วยตรวจสอบโค้ดก่อนที่จะ Merge เข้าสู่ Branch หลักจะช่วยจับข้อผิดพลาดและช่องโหว่ที่อาจเกิดขึ้นได้

การใช้ OIDC สำหรับการเชื่อมต่อ Cloud

OpenID Connect (OIDC) ช่วยให้ GitHub Actions สามารถแลกเปลี่ยน Token กับ Cloud Providers (AWS, Azure, GCP) เพื่อขอ Credentials ชั่วคราวได้ครับ ซึ่งปลอดภัยกว่าการใช้ Long-lived Access Key/Secret Key ที่คุณต้องเก็บเป็น GitHub Secret

ประโยชน์ของ OIDC:

  • ไม่มี Long-lived Credentials: ไม่ต้องเก็บ Access Key/Secret Key ใน GitHub Secrets
  • ลดความเสี่ยง: Credentials ที่ได้มามีอายุสั้นและมีสิทธิ์ตามที่กำหนดเท่านั้น
  • ง่ายต่อการจัดการ: ไม่ต้องหมุนเวียน Key บ่อยๆ

การตั้งค่า OIDC จะแตกต่างกันไปตาม Cloud Provider แต่โดยทั่วไปจะเกี่ยวข้องกับการกำหนด Trust Policy ใน IAM (Identity and Access Management) ของ Cloud Provider เพื่ออนุญาตให้ GitHub ID Token สามารถขอ Role ชั่วคราวได้ครับ

การประยุกต์ใช้ GitHub Actions กับสถานการณ์จริง

GitHub Actions ไม่ได้จำกัดอยู่แค่การ Build และ Deploy เว็บไซต์เท่านั้นครับ แต่สามารถประยุกต์ใช้ได้กับสถานการณ์การพัฒนาซอฟต์แวร์ที่หลากหลายและซับซ้อน

Mobile App CI/CD (Android/iOS)

การ Build และ Deploy Mobile App เป็นกระบวนการที่ซับซ้อน แต่ GitHub Actions ก็สามารถจัดการได้ครับ

  • Android:
    • CI: ใช้ actions/setup-java@v3 และ gradle/gradle-build-action@v2 เพื่อ Build และรัน Unit Tests สำหรับโปรเจกต์ Android
    • CD: ใช้ Action สำหรับ Deploy ไปยัง Firebase App Distribution, Google Play Store (fastlane, r0adkll/upload-google-play@v1) หรือ Artifact Management อื่นๆ
  • iOS:
    • CI: ต้องใช้ runs-on: macos-latest เนื่องจากต้องรันบน macOS เพื่อ Build iOS App
    • CI: ใช้ actions/setup-ruby@v1 และ fastlane เพื่อ Build และรัน Unit Tests สำหรับโปรเจกต์ iOS
    • CD: ใช้ Action สำหรับ Deploy ไปยัง TestFlight หรือ App Store Connect ผ่าน fastlane
  • การจัดการ Code Signing: จัดเก็บ Certificate และ Provisioning Profile อย่างปลอดภัยใน GitHub Secrets และนำมาใช้ระหว่างการ Build

Microservices Deployment

สำหรับสถาปัตยกรรม Microservices ที่มีบริการย่อยๆ จำนวนมาก GitHub Actions สามารถช่วยจัดการ CI/CD ของแต่ละ Microservice แยกกันได้ครับ

  • Monorepo หรือ Polyrepo: ไม่ว่าคุณจะใช้ Monorepo (หลาย Microservice ใน Repository เดียว) หรือ Polyrepo (แต่ละ Microservice มี Repository ของตัวเอง) GitHub Actions ก็รองรับทั้งหมด
  • Conditional Deployment: กำหนดให้ Workflow ทำงานและ Deploy เฉพาะ Microservice ที่มีการเปลี่ยนแปลงโค้ดเท่านั้น เพื่อประหยัดทรัพยากรและเวลา
  • Containerization: Build Docker Image สำหรับแต่ละ Microservice และ Push ไปยัง Container Registry (เช่น Docker Hub, ECR, GCR)
  • Orchestration: Deploy Container ไปยัง Kubernetes, ECS, Azure Kubernetes Service (AKS) หรือ Google Kubernetes Engine (GKE) โดยใช้ Actions ที่เกี่ยวข้องกับการจัดการ Kubernetes

Infrastructure as Code (IaC)

Infrastructure as Code (IaC) คือการจัดการและ Provision Infrastructure ผ่านโค้ดครับ GitHub Actions สามารถใช้ในการ Automate กระบวนการ IaC ได้ เช่น:

  • Terraform: ใช้ hashicorp/setup-terraform@v2 เพื่อตั้งค่า Terraform และรันคำสั่ง terraform plan เพื่อตรวจสอบการเปลี่ยนแปลง และ terraform apply เพื่อ Provision Infrastructure
  • CloudFormation/ARM Templates: ใช้ AWS CLI หรือ Azure CLI เพื่อ Deploy CloudFormation Stacks หรือ ARM Templates
  • Ansible/Chef/Puppet: รัน Playbook หรือ Recipe สำหรับ Configuration Management

การใช้ GitHub Actions สำหรับ IaC ช่วยให้คุณมั่นใจได้ว่า Infrastructure ของคุณถูกจัดการอย่างสอดคล้องกัน และสามารถ Rollback ได้ง่ายหากเกิดปัญหาครับ

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

  1. GitHub Actions ฟรีหรือไม่?

    สำหรับ Public Repository นั้น GitHub Actions ฟรีไม่จำกัดจำนวนนาทีใช้งานครับ สำหรับ Private Repository จะมีโควต้าฟรีจำนวนหนึ่ง (เช่น 2,000 นาที/เดือน สำหรับบัญชี Free) หากใช้งานเกินโควต้าก็จะมีการคิดค่าใช้จ่ายตามนาทีที่ใช้งานครับ โดยราคาจะแตกต่างกันไปตามระบบปฏิบัติการของ Runner (Ubuntu, Windows, macOS) ครับ

  2. เราจะรัน Workflow ด้วยตนเองได้อย่างไร?

    คุณสามารถเพิ่ม workflow_dispatch: ในส่วน on: ของ Workflow ของคุณครับ เมื่อเพิ่มแล้ว คุณจะเห็นปุ่ม “Run workflow” ในแท็บ “Actions” บน GitHub UI ซึ่งช่วยให้คุณสามารถเลือก Branch และรัน Workflow ได้ด้วยตนเองครับ

  3. GitHub Actions สามารถ Deploy ไปยัง Server ของเราเองได้หรือไม่?

    ได้ครับ คุณสามารถใช้ Self-hosted Runners ที่คุณติดตั้งบน Server ของคุณเองได้ ซึ่งจะช่วยให้ Workflow ของคุณสามารถเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัวของคุณได้ หรือคุณสามารถใช้ SSH Action (เช่น appleboy/ssh-action@master) เพื่อเชื่อมต่อไปยัง Server และรันคำสั่ง Deploy ได้โดยตรงครับ

  4. เราจะจัดการเวอร์ชันของ Actions ที่ใช้ใน Workflow ได้อย่างไร?

    แนะนำให้ระบุเวอร์ชันของ Action อย่างชัดเจนครับ เช่น uses: actions/checkout@v4 แทนที่จะเป็น actions/checkout@main หรือ actions/checkout เฉยๆ การระบุเวอร์ชันจะช่วยให้ Workflow ของคุณมีความเสถียรและไม่ได้รับผลกระทบจากการเปลี่ยนแปลงที่ไม่คาดคิดใน Action เวอร์ชันใหม่ครับ คุณสามารถระบุเวอร์ชันหลัก (v4) หรือเวอร์ชันที่เจาะจงมากขึ้น (v4.0.0) ก็ได้ครับ

  5. ทำไม Workflow ของฉันถึงไม่ทำงาน หรือรันแล้วล้มเหลว?

    มีหลายสาเหตุที่ Workflow อาจไม่ทำงานหรือล้มเหลวครับ:

    • Event ไม่ตรง: ตรวจสอบว่า Event ที่กำหนดใน on: ตรงกับกิจกรรมที่คุณคาดหวังหรือไม่ (เช่น Push ไปที่ Branch ที่ถูกต้อง)
    • Syntax Error ใน YAML: ไฟล์ YAML มีความอ่อนไหวต่อ Indentation และ Syntax ตรวจสอบให้แน่ใจว่าถูกต้อง
    • คำสั่ง Shell ล้มเหลว: ตรวจสอบ Log ของ Step ที่ล้มเหลวเพื่อดู Error Message จากคำสั่ง Shell
    • Dependencies ไม่ครบ: ตรวจสอบว่า Step การติดตั้ง Dependencies ทำงานถูกต้องและครบถ้วน
    • Secrets ไม่ถูกต้อง/ไม่ได้รับอนุญาต: ตรวจสอบว่า Secret ที่ใช้มีอยู่จริง และ Runner มีสิทธิ์เข้าถึง Secret นั้นๆ
    • Runner ไม่มี Resource เพียงพอ: สำหรับ Self-hosted Runners อาจมีปัญหาเรื่อง CPU/Memory ไม่พอ หรือพื้นที่ดิสก์เต็มครับ

    คำแนะนำคือ ให้ดู Log ของ Workflow Run อย่างละเอียดในแท็บ “Actions” เพื่อหาข้อผิดพลาดที่เกิดขึ้นครับ

สรุป: ก้าวสู่การพัฒนาที่รวดเร็วและมีประสิทธิภาพ

ในบทความนี้ เราได้เดินทางผ่านโลกของ CI/CD Pipeline และเจาะลึกการสร้างระบบอัตโนมัติด้วย GitHub Actions กันอย่างละเอียดแล้วนะครับ ตั้งแต่ความเข้าใจพื้นฐานของ Continuous Integration และ Continuous Delivery ไปจนถึงส่วนประกอบสำคัญของ GitHub Actions, การสร้าง Workflow สำหรับ Build, Test, และ Deploy จริงๆ รวมถึง Best Practices และข้อควรพิจารณาด้านความปลอดภัยต่างๆ

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

ถึงเวลาที่คุณจะเริ่มต้นแล้วครับ! อย่ารอช้าที่จะนำ GitHub Actions ไปใช้กับโปรเจกต์ถัดไปของคุณ ไม่ว่าจะเป็นการสร้าง CI สำหรับการทดสอบโค้ด, การ Deploy เว็บไซต์อัตโนมัติ, หรือแม้แต่การจัดการ Infrastructure as Code ก็ตาม เริ่มต้นจาก Workflow ง่ายๆ แล้วค่อยๆ เพิ่มความซับซ้อนตามความต้องการของโปรเจกต์คุณได้เลยครับ หากคุณมีคำถามหรือต้องการเรียนรู้เพิ่มเติม อย่าลังเลที่จะศึกษาจากเอกสารของ GitHub Actions หรือชุมชนนักพัฒนาที่พร้อมจะให้ความช่วยเหลือครับ

มาร่วมกันสร้างสรรค์ซอฟต์แวร์ที่มีคุณภาพและส่งมอบได้อย่างรวดเร็วด้วยพลังของ GitHub Actions กันนะครับ!

กลับสู่หน้าแรกของ SiamLancard.com

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

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