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

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

March 17, 2026
0 Views

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

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

สารบัญ

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

CI/CD Pipeline คือชุดของขั้นตอนอัตโนมัติที่ช่วยให้นักพัฒนาสามารถส่งมอบโค้ดไปยังผู้ใช้งานได้อย่างรวดเร็วและปลอดภัย โดยแบ่งออกเป็นสองส่วนหลักๆ คือ Continuous Integration (CI) และ Continuous Delivery/Deployment (CD) ครับ

Continuous Integration (CI)

Continuous Integration (CI) คือแนวทางปฏิบัติที่นักพัฒนาทุกคนผสานรวม (integrate) โค้ดของตนเองเข้ากับ mainline (มักจะเป็น `main` หรือ `master` branch) บ่อยครั้งที่สุดเท่าที่จะทำได้ โดยปกติแล้วจะรวมโค้ดหลายครั้งต่อวัน การรวมโค้ดแต่ละครั้งจะถูกตรวจสอบโดยระบบอัตโนมัติ ซึ่งรวมถึง:

  • Build: การคอมไพล์โค้ด การสร้างแพ็กเกจ หรือการสร้าง Docker image ครับ
  • Test: การรันชุดทดสอบอัตโนมัติ เช่น Unit Tests, Integration Tests, หรือ Linting เพื่อตรวจสอบข้อผิดพลาดและคุณภาพของโค้ดครับ

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

Continuous Delivery (CD)

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

  • Package: สร้าง Artifact ที่พร้อมสำหรับการ Deploy ครับ
  • Release: เตรียม Artifact นั้นให้พร้อมสำหรับการ Deploy ไปยังสภาพแวดล้อมต่างๆ เช่น Staging, UAT (User Acceptance Testing) หรือ Production ครับ

ใน Continuous Delivery การ Deploy ไปยัง Production มักจะยังต้องอาศัยการอนุมัติด้วยตนเอง (manual approval) เพื่อให้ทีมสามารถตัดสินใจได้ว่าจะปล่อยเวอร์ชันใหม่เมื่อใดครับ

Continuous Deployment (CD)

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

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

การนำ CI/CD มาใช้ในกระบวนการพัฒนาซอฟต์แวร์มีประโยชน์มากมายที่ส่งผลต่อประสิทธิภาพและคุณภาพของผลิตภัณฑ์โดยรวมครับ:

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

ทำความรู้จัก GitHub Actions

GitHub Actions คือแพลตฟอร์ม CI/CD ที่มาพร้อมกับ GitHub ซึ่งช่วยให้คุณสามารถสร้าง Automation Workflow ที่ตอบสนองต่อ Event ต่างๆ ใน GitHub Repository ของคุณได้ครับ ไม่ว่าจะเป็นการ push โค้ด, การเปิด Pull Request, การสร้าง Release หรือ Event อื่นๆ อีกมากมาย GitHub Actions ช่วยให้คุณสามารถ Build, Test, และ Deploy โค้ดของคุณได้โดยตรงจาก GitHub โดยไม่ต้องใช้เครื่องมือภายนอกเพิ่มเติมครับ

หัวใจสำคัญของ GitHub Actions คือการใช้ไฟล์ YAML ในการกำหนด Workflow ซึ่งเป็นชุดของขั้นตอน (Steps) ที่รัน Job ต่างๆ บน Runner ที่เป็น Virtual Machine หรือ Container ครับ ด้วย GitHub Actions คุณสามารถ Automate ได้เกือบทุกอย่าง ตั้งแต่กระบวนการพัฒนาซอฟต์แวร์ไปจนถึงการจัดการ Infrastructure as Code เลยทีเดียวครับ

แนวคิดหลักของ GitHub Actions

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

Workflows

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

# .github/workflows/my-workflow.yml
name: My First Workflow

on: [push] # Triggered on every push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Say Hello
        run: echo "Hello from GitHub Actions!"

Events

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

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

คุณสามารถกำหนด Event ได้หลายตัวใน Workflow เดียวกันได้ครับ

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

Jobs

Job คือชุดของ Steps ที่รันบน Runner เดียวกันครับ โดย Workflow สามารถมีได้ตั้งแต่หนึ่ง Job ขึ้นไป และแต่ละ Job จะรันแยกกัน (parallel) โดยดีฟอลต์ แต่คุณก็สามารถกำหนด Dependency ระหว่าง Job ได้โดยใช้คีย์เวิร์ด needs ครับ

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # ... build steps ...
  test:
    runs-on: ubuntu-latest
    needs: build # This job will run only after the 'build' job completes successfully
    steps:
      # ... test steps ...

Steps

Step คือ Task ที่เป็นส่วนหนึ่งของ Job ครับ Step สามารถเป็นได้ทั้ง Script (คำสั่ง Shell) หรือ Action (Action ที่ถูกสร้างไว้ล่วงหน้า) ครับ แต่ละ Step จะรันตามลำดับที่กำหนดไว้ใน Job ครับ

steps:
  - name: Install dependencies # A script step
    run: npm install
  - name: Run tests # Another script step
    run: npm test
  - name: Checkout code # An action step
    uses: actions/checkout@v4

Actions

Action คือหน่วยของงานที่นำมาใช้ซ้ำได้ ซึ่งช่วยลดความจำเป็นในการเขียน Script ที่ซับซ้อนด้วยตนเองครับ GitHub Marketplace มี Actions มากมายที่สร้างโดย GitHub และชุมชน เช่น actions/checkout สำหรับการดึงโค้ด, actions/setup-node สำหรับการติดตั้ง Node.js หรือ Actions สำหรับการ Deploy ไปยัง Cloud Provider ต่างๆ ครับ

คุณสามารถใช้ Actions ได้โดยระบุ uses: <owner>/<repo>@<version> หรือ ./.github/actions/my-custom-action สำหรับ Custom Action ใน Repository ของคุณครับ

steps:
  - uses: actions/checkout@v4 # Uses a community action
  - uses: actions/setup-node@v4
    with:
      node-version: '20'

Runners

Runner คือเซิร์ฟเวอร์ที่รัน Workflow ของคุณครับ GitHub Actions มี Hosted Runners ให้บริการ ซึ่งเป็น Virtual Machine ที่มีระบบปฏิบัติการและเครื่องมือพื้นฐานต่างๆ ติดตั้งมาให้แล้ว เช่น Ubuntu, Windows, macOS ครับ คุณเพียงแค่ระบุ runs-on: ubuntu-latest หรือ runs-on: windows-latest ครับ

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

การออกแบบ CI/CD Pipeline ที่มีประสิทธิภาพ

การออกแบบ Pipeline ที่ดีเป็นสิ่งสำคัญเพื่อให้ CI/CD ทำงานได้อย่างราบรื่นและเกิดประโยชน์สูงสุดครับ

การวิเคราะห์ความต้องการและโครงสร้างโปรเจกต์

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

  • ภาษาและ Framework: ใช้ภาษาและ Framework อะไร? (เช่น Node.js, Python, Java, .NET) สิ่งนี้จะกำหนดว่าคุณต้องติดตั้ง Dependency ใดบ้าง และใช้คำสั่ง Build/Test อย่างไรครับ
  • เครื่องมือทดสอบ: มี Unit Test, Integration Test, E2E Test หรือไม่? ใช้ Framework อะไรในการทดสอบ? (เช่น Jest, Pytest, JUnit, Cypress)
  • เครื่องมือ Linting/Static Analysis: มีการใช้ ESLint, Black, SonarQube หรือไม่?
  • วิธีการ Build: โปรเจกต์ของคุณ Build อย่างไร? (เช่น npm run build, mvn package, docker build)
  • เป้าหมายการ Deploy: คุณต้องการ Deploy ไปที่ไหน? (เช่น AWS S3, EC2, ECS, EKS, Heroku, Azure App Service, Docker Hub)

กลยุทธ์การแตกสาขา (Branching Strategy)

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

  • GitFlow: เหมาะสำหรับโปรเจกต์ขนาดใหญ่ที่มี Release Cycle ที่ชัดเจน มี Branch หลักหลายประเภท (main, develop, feature, release, hotfix) ครับ
  • GitHub Flow: ง่ายและตรงไปตรงมา เหมาะสำหรับโปรเจกต์ที่ต้องการ Deploy บ่อยครั้ง โดยมี Branch หลักคือ main และใช้ Feature Branch สำหรับการพัฒนาฟีเจอร์ใหม่ๆ ครับ
  • Trunk-Based Development: นักพัฒนาทุกคนทำงานบน Branch หลัก (Trunk) โดยตรง หรือใช้ Short-Lived Feature Branch ที่รวมกลับเข้า Trunk อย่างรวดเร็ว เหมาะสำหรับทีมที่ต้องการ Continuous Deployment ระดับสูงครับ

สำหรับบทความนี้ เราจะเน้นที่ GitHub Flow ซึ่งเป็นที่นิยมและเข้ากันได้ดีกับ GitHub Actions ครับ โดย Workflow CI มักจะถูก Trigger เมื่อมีการ Push หรือ Pull Request ไปยัง Feature Branch และเมื่อมีการรวมโค้ดเข้าสู่ main Branch ก็จะ Trigger Workflow CD เพื่อ Deploy ครับ

ข้อควรพิจารณาด้านความปลอดภัย

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

  • Secrets: ไม่ควรเก็บข้อมูลที่ละเอียดอ่อน เช่น API Keys, Passwords, Access Tokens ไว้ในโค้ดหรือไฟล์ Workflow โดยตรงครับ GitHub Actions มีคุณสมบัติ Secrets ที่ช่วยให้คุณเก็บข้อมูลเหล่านี้ได้อย่างปลอดภัยและเรียกใช้ใน Workflow ได้ครับ
  • Permissions: กำหนด Permission ให้กับ Access Token ที่ใช้ใน Workflow อย่างรัดกุมที่สุดเท่าที่จำเป็น (Least Privilege) ครับ
  • Vulnerability Scanning: ใช้ Actions สำหรับการสแกนช่องโหว่ของโค้ดและ Dependency (เช่น Dependabot, Snyk) เพื่อตรวจจับและแก้ไขปัญหาด้านความปลอดภัยตั้งแต่เนิ่นๆ ครับ

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

เราจะมาสร้าง CI Pipeline สำหรับโปรเจกต์ Node.js อย่างง่ายๆ กันครับ Pipeline นี้จะประกอบด้วยการติดตั้ง Dependency, การรัน Linting, การรัน Unit Test และการ Build โปรเจกต์ครับ

การเตรียมโปรเจกต์ตัวอย่าง

สร้างโปรเจกต์ Node.js อย่างง่ายๆ พร้อมไฟล์สำหรับทดสอบและ Linting ครับ

  1. สร้างโฟลเดอร์โปรเจกต์: mkdir my-nodejs-app && cd my-nodejs-app
  2. เริ่มต้น Node.js project: npm init -y
  3. ติดตั้ง Express (สำหรับตัวอย่าง API): npm install express
  4. ติดตั้ง Jest (สำหรับ Unit Test): npm install --save-dev jest
  5. ติดตั้ง ESLint (สำหรับ Linting): npm install --save-dev eslint และตั้งค่า ESLint ด้วย npx eslint --init (เลือกตามความเหมาะสม)

สร้างไฟล์ index.js:

// index.js
const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
  res.send('Hello from Node.js App!');
});

app.get('/api/greeting/:name', (req, res) => {
  const name = req.params.name;
  if (!name) {
    return res.status(400).send('Name is required');
  }
  res.send(`Hello, ${name}!`);
});

const startServer = () => {
  app.listen(port, () => {
    console.log(`App listening at http://localhost:${port}`);
  });
};

module.exports = { app, startServer }; // Export app for testing

สร้างไฟล์ index.test.js:

// index.test.js
const request = require('supertest');
const { app } = require('./index');

describe('GET /', () => {
  it('should return "Hello from Node.js App!"', async () => {
    const res = await request(app).get('/');
    expect(res.statusCode).toEqual(200);
    expect(res.text).toEqual('Hello from Node.js App!');
  });
});

describe('GET /api/greeting/:name', () => {
  it('should return "Hello, John!" when name is "John"', async () => {
    const res = await request(app).get('/api/greeting/John');
    expect(res.statusCode).toEqual(200);
    expect(res.text).toEqual('Hello, John!');
  });

  it('should return 400 if name is missing', async () => {
    const res = await request(app).get('/api/greeting/');
    expect(res.statusCode).toEqual(404); // Express default 404 for unmatched route
  });
});

แก้ไข package.json เพื่อเพิ่ม Script สำหรับ Test และ Lint:

  "scripts": {
    "start": "node index.js",
    "test": "jest",
    "lint": "eslint .",
    "build": "echo \"No build step needed for this simple app, but for complex apps it would involve webpack/rollup etc.\""
  },

การสร้างไฟล์ Workflow สำหรับ CI (.github/workflows/ci.yml)

สร้างไฟล์ .github/workflows/ci.yml ใน Repository ของคุณครับ

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

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main", "develop" ]
  workflow_dispatch: # Allows manual trigger

jobs:
  build_and_test:
    runs-on: ubuntu-latest

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

    - name: Setup Node.js environment
      uses: actions/setup-node@v4
      with:
        node-version: '20' # Specify Node.js version
        cache: 'npm'       # Cache npm dependencies

    - name: Install dependencies
      run: npm install

    - name: Run ESLint
      run: npm run lint

    - name: Run Unit Tests
      run: npm test

    - name: Build application (if applicable)
      run: npm run build

    - name: Archive production artifacts (optional)
      uses: actions/upload-artifact@v4
      with:
        name: node-app-build
        path: . # In this simple example, we upload the whole directory. For real apps, specify build output directory

ทำความเข้าใจ CI Workflow แต่ละส่วน

  1. name: Node.js CI: ชื่อของ Workflow ที่จะแสดงในหน้า GitHub Actions ครับ
  2. on:: กำหนด Event ที่จะ Trigger Workflow นี้
    • push: เมื่อมีการ Push โค้ดไปยัง Branch main หรือ develop ครับ
    • pull_request: เมื่อมีการสร้างหรืออัปเดต Pull Request ที่มีเป้าหมายไปยัง Branch main หรือ develop ครับ
    • workflow_dispatch: อนุญาตให้เรียกใช้ Workflow นี้ได้ด้วยตนเองผ่าน GitHub UI ครับ
  3. jobs:: กำหนด Job ต่างๆ ใน Workflow นี้
    • build_and_test:: ชื่อ Job นี้คือ “build_and_test” ครับ
      • runs-on: ubuntu-latest: ระบุว่า Job นี้จะรันบน Ubuntu Virtual Machine เวอร์ชันล่าสุดที่ GitHub จัดหาให้ครับ
      • steps:: ลำดับของ Task ที่จะรันใน Job นี้
        • - name: Checkout code:
          • uses: actions/checkout@v4: ใช้ Action checkout เพื่อดึงโค้ดจาก Repository มายัง Runner ครับ นี่คือ Step แรกที่จำเป็นเกือบทุก Workflow ครับ
        • - name: Setup Node.js environment:
          • uses: actions/setup-node@v4: ใช้ Action setup-node เพื่อติดตั้ง Node.js เวอร์ชันที่ต้องการครับ
          • with:: กำหนด Input สำหรับ Action นี้
            • node-version: '20': ติดตั้ง Node.js เวอร์ชัน 20 ครับ
            • cache: 'npm': เปิดใช้งานการ Cache Dependency ของ npm ซึ่งช่วยให้การติดตั้งรวดเร็วขึ้นในการรันครั้งต่อไปครับ
        • - name: Install dependencies:
          • run: npm install: รันคำสั่ง npm install เพื่อติดตั้งแพ็กเกจที่ระบุใน package.json ครับ
        • - name: Run ESLint:
          • run: npm run lint: รัน Script lint ที่กำหนดไว้ใน package.json เพื่อตรวจสอบคุณภาพโค้ดครับ
        • - name: Run Unit Tests:
          • run: npm test: รัน Script test ที่กำหนดไว้ใน package.json เพื่อรัน Unit Tests ครับ
        • - name: Build application (if applicable):
          • run: npm run build: รัน Script build ครับ ในโปรเจกต์ Node.js ที่เป็น Backend หรือ API อาจจะไม่มี Build step ที่ซับซ้อนมากนัก แต่สำหรับ Frontend หรือโปรเจกต์ที่ต้อง Compile อาจจะมี Webpack, Rollup หรือ TypeScript Compilation ที่นี่ครับ
        • - name: Archive production artifacts (optional):
          • uses: actions/upload-artifact@v4: ใช้ Action upload-artifact เพื่ออัปโหลดไฟล์หรือโฟลเดอร์ที่เป็นผลลัพธ์ของ Build (Artifact) ไปยัง GitHub เพื่อให้ Job อื่นๆ หรือ Workflow อื่นๆ สามารถดาวน์โหลดไปใช้ได้ครับ สิ่งนี้สำคัญมากสำหรับกระบวนการ CD ครับ
          • with::
            • name: node-app-build: ชื่อของ Artifact ครับ
            • path: .: ระบุเส้นทางของไฟล์/โฟลเดอร์ที่จะอัปโหลดครับ ในตัวอย่างนี้ เราอัปโหลดทั้ง Repository เพื่อความง่าย แต่ในสถานการณ์จริง คุณควรกำหนดเฉพาะโฟลเดอร์ Build Output (เช่น dist, build) ครับ

การจัดการ Artifacts

Artifacts เป็นผลลัพธ์ที่สร้างขึ้นโดย Workflow ซึ่งอาจเป็นไฟล์ Build, แพ็กเกจ, หรือรายงานการทดสอบครับ การอัปโหลด Artifacts (ด้วย actions/upload-artifact) และการดาวน์โหลด Artifacts (ด้วย actions/download-artifact) เป็นสิ่งสำคัญในการส่งผ่านข้อมูลระหว่าง Job หรือ Workflow ครับ

ใน CI Pipeline เรามักจะอัปโหลด Artifacts ที่เป็นผลลัพธ์ของการ Build เพื่อให้ CD Pipeline สามารถนำไป Deploy ได้โดยไม่ต้อง Build ซ้ำครับ

สร้าง CD Pipeline ด้วย GitHub Actions (ตัวอย่าง Docker และ AWS ECR/ECS)

เมื่อ CI Pipeline ของเราผ่านแล้ว ขั้นตอนต่อไปคือการสร้าง CD Pipeline เพื่อ Deploy แอปพลิเคชันของเราครับ ในตัวอย่างนี้ เราจะสาธิตการสร้าง Docker Image, Push ไปยัง AWS Elastic Container Registry (ECR) และ Deploy ไปยัง AWS Elastic Container Service (ECS) ซึ่งเป็นรูปแบบที่นิยมสำหรับการ Deploy Containerized Applications ครับ

กลยุทธ์การ Deploy

ก่อนจะเริ่มสร้าง Workflow เรามาทำความเข้าใจกลยุทธ์การ Deploy ที่พบบ่อยกันก่อนครับ

  • Blue/Green Deployment: รันเวอร์ชันใหม่ (Green) ควบคู่ไปกับเวอร์ชันเก่า (Blue) จากนั้นค่อยๆ เปลี่ยน Traffic ไปยังเวอร์ชันใหม่ เมื่อมั่นใจว่าเวอร์ชันใหม่ทำงานได้ถูกต้อง จึงปิดเวอร์ชันเก่าครับ ช่วยลด Downtime และความเสี่ยงครับ
  • Canary Deployment: ค่อยๆ ปล่อยเวอร์ชันใหม่ให้กับผู้ใช้กลุ่มเล็กๆ ก่อน เพื่อตรวจสอบประสิทธิภาพและข้อผิดพลาด ก่อนที่จะปล่อยให้ผู้ใช้ทั้งหมดครับ
  • Rolling Deployment: ค่อยๆ อัปเดต Instance ทีละน้อย โดยนำ Instance เก่าออกและแทนที่ด้วย Instance ใหม่ครับ
  • All-at-once Deployment: ปิดแอปพลิเคชันทั้งหมดแล้ว Deploy เวอร์ชันใหม่ทั้งหมดพร้อมกัน มักใช้กับแอปพลิเคชันที่ไม่ต้องการ Uptime ตลอดเวลาครับ

สำหรับตัวอย่างนี้ เราจะใช้การ Deploy แบบง่ายๆ โดยการอัปเดต Service ใน ECS ซึ่งโดยทั่วไปจะใช้กลยุทธ์ Rolling Update โดยดีฟอลต์ครับ

การสร้างไฟล์ Workflow สำหรับ CD (.github/workflows/cd.yml)

ก่อนอื่น คุณจะต้องมี Repository บน GitHub ที่มีโค้ด Node.js พร้อมไฟล์ Dockerfile ครับ

สร้างไฟล์ Dockerfile ในโปรเจกต์ของคุณ:

# Dockerfile
# Use an official Node.js runtime as a parent image
FROM node:20-slim

# Set the working directory in the container
WORKDIR /app

# Copy package.json and package-lock.json to the working directory
# to install dependencies first
COPY package*.json ./

# Install application dependencies
RUN npm install --production

# Copy the rest of the application code
COPY . .

# Expose the port the app runs on
EXPOSE 3000

# Run the application
CMD [ "npm", "start" ]

จากนั้น สร้างไฟล์ .github/workflows/cd.yml:

# .github/workflows/cd.yml
name: CD to AWS ECR & ECS

on:
  push:
    branches: [ "main" ] # Trigger only on pushes to main branch
  workflow_dispatch: # Allows manual trigger

env: # Environment variables for the entire workflow
  AWS_REGION: ap-southeast-1 # e.g., us-east-1, ap-southeast-1
  ECR_REPOSITORY: my-nodejs-app # Name of your ECR repository
  ECS_SERVICE: my-nodejs-service # Name of your ECS Service
  ECS_CLUSTER: my-nodejs-cluster # Name of your ECS Cluster
  ECS_TASK_DEFINITION: .github/workflows/task-definition.json # Path to your task definition file
  CONTAINER_NAME: nodejs-app-container # Name of the container in the task definition

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production # Link to a GitHub Environment for production

    permissions:
      contents: read
      id-token: write # Required for OIDC authentication with AWS

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

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/GitHubActionsOIDCProviderRole # Replace with your IAM Role ARN
        aws-region: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v2

    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

    - name: Download task definition
      uses: actions/download-artifact@v4
      with:
        name: task-definition-artifact # If you upload this in CI, uncomment and adjust
        path: .

    - name: Fill in the new image ID in the Amazon ECS task definition
      id: render-task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.build-image.outputs.image }}

    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.render-task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

นอกจากนี้ คุณจะต้องมีไฟล์ .github/workflows/task-definition.json ซึ่งเป็น Template สำหรับ ECS Task Definition ของคุณครับ (คุณสามารถดาวน์โหลดจาก ECS Console ได้ครับ)

// .github/workflows/task-definition.json (Simplified example)
{
  "family": "my-nodejs-app-task",
  "taskRoleArn": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/ecsTaskExecutionRole",
  "executionRoleArn": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512",
  "requiresCompatibilities": [ "FARGATE" ],
  "containerDefinitions": [
    {
      "name": "nodejs-app-container",
      "image": "YOUR_AWS_ACCOUNT_ID.dkr.ecr.ap-southeast-1.amazonaws.com/my-nodejs-app:latest", // Placeholder, will be replaced by action
      "portMappings": [
        {
          "containerPort": 3000,
          "hostPort": 3000,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-nodejs-app",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

หมายเหตุ: การตั้งค่า AWS IAM Role สำหรับ OIDC (OpenID Connect) เป็นสิ่งจำเป็นสำหรับ aws-actions/configure-aws-credentials@v4 ครับ คุณต้องตั้งค่า IAM Identity Provider ใน AWS และสร้าง IAM Role ที่อนุญาตให้ GitHub Actions เข้าถึงทรัพยากร AWS ของคุณได้ครับ อ่านเพิ่มเติมเกี่ยวกับ OIDC กับ AWS

ทำความเข้าใจ CD Workflow แต่ละส่วน

  1. name: CD to AWS ECR & ECS: ชื่อของ Workflow ครับ
  2. on:: Trigger Workflow นี้เมื่อมีการ Push โค้ดไปยัง Branch main เท่านั้น เพื่อให้แน่ใจว่าโค้ดที่ Deploy คือโค้ดที่ผ่านการตรวจสอบและผสานรวมแล้วครับ
  3. env:: กำหนด Environment Variables ที่จะใช้ตลอด Workflow ครับ ช่วยให้การจัดการค่าต่างๆ ง่ายขึ้นครับ
  4. jobs:
    • deploy:: ชื่อ Job สำหรับการ Deploy ครับ
      • runs-on: ubuntu-latest: รันบน Ubuntu Runner ครับ
      • environment: production: เชื่อมโยง Job นี้กับ GitHub Environment ที่ชื่อ production ครับ ซึ่งสามารถกำหนด Protection Rules เช่น Manual Approval ได้ครับ
      • permissions:: กำหนด Permission สำหรับ GITHUB_TOKEN ที่จะใช้ใน Job นี้
        • id-token: write: จำเป็นสำหรับ OIDC authentication กับ AWS ครับ
      • steps:
        • - name: Checkout code: ดึงโค้ดโปรเจกต์มาครับ
        • - name: Configure AWS Credentials:
          • uses: aws-actions/configure-aws-credentials@v4: ใช้ Action นี้เพื่อตั้งค่า AWS Credentials โดยใช้ OIDC Role ครับ คุณต้องแทนที่ YOUR_AWS_ACCOUNT_ID ด้วย AWS Account ID ของคุณและ GitHubActionsOIDCProviderRole ด้วยชื่อ Role ที่คุณสร้างไว้ครับ
          • aws-region: ${{ env.AWS_REGION }}: กำหนด Region ของ AWS ครับ
        • - name: Login to Amazon ECR:
          • uses: aws-actions/amazon-ecr-login@v2: ใช้ Action นี้เพื่อ Login ไปยัง ECR Registry ครับ
          • id: login-ecr: กำหนด ID ให้ Step นี้ เพื่อให้สามารถอ้างอิง Output ของ Step นี้ได้ (เช่น steps.login-ecr.outputs.registry) ครับ
        • - name: Build, tag, and push image to Amazon ECR:
          • env:: กำหนด Environment Variables เฉพาะสำหรับ Step นี้
          • run: | ...: รันคำสั่ง Docker เพื่อ Build Image, Tag ด้วย SHA ของ Commit และ Push ไปยัง ECR ครับ
          • echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT: ตั้งค่า Output ของ Step นี้ เพื่อให้ Step อื่นๆ สามารถนำ Image URI ไปใช้ได้ครับ
        • - name: Download task definition: ถ้าคุณมีการสร้าง Task Definition แบบ Dynamic ใน CI Workflow คุณสามารถใช้ actions/download-artifact เพื่อดาวน์โหลดมาที่นี่ได้ครับ ในตัวอย่างนี้เราใช้ไฟล์ที่อยู่ใน Repository โดยตรงครับ
        • - name: Fill in the new image ID in the Amazon ECS task definition:
          • uses: aws-actions/amazon-ecs-render-task-definition@v1: ใช้ Action นี้เพื่ออัปเดต Image URI ใน Task Definition JSON ไฟล์ ด้วย Image ที่เราเพิ่ง Build และ Push ไปยัง ECR ครับ
          • task-definition, container-name, image: ระบุพารามิเตอร์ที่จำเป็นครับ
        • - name: Deploy Amazon ECS task definition:
          • uses: aws-actions/amazon-ecs-deploy-task-definition@v1: ใช้ Action นี้เพื่อ Deploy Task Definition ที่อัปเดตแล้วไปยัง ECS Service ของคุณครับ
          • task-definition, service, cluster: ระบุพารามิเตอร์ที่จำเป็นครับ
          • wait-for-service-stability: true: รอจนกว่า ECS Service จะเสถียรหลังจาก Deploy ครับ

การจัดการ Secrets และ Environment Variables

  • Secrets: สำหรับข้อมูลที่ละเอียดอ่อน เช่น AWS Access Key ID, Secret Access Key (แม้จะแนะนำ OIDC มากกว่า), หรือ Token อื่นๆ ให้ใช้ GitHub Secrets ครับ ไปที่ Settings > Secrets and variables > Actions แล้วเพิ่ม Secret ใหม่ครับ จากนั้นใน Workflow คุณสามารถเรียกใช้ได้ด้วย ${{ secrets.MY_SECRET_NAME }} ครับ
  • Environment Variables: สำหรับค่าที่ไม่ละเอียดอ่อนและมีการเปลี่ยนแปลงบ่อย สามารถกำหนดเป็น env ใน Workflow ได้ครับ สามารถกำหนดได้ทั้งระดับ Workflow หรือระดับ Job หรือแม้แต่ระดับ Step ครับ

ตัวอย่างการใช้ Secrets: (หากคุณยังไม่ได้ใช้ OIDC และต้องการใช้ Access Key)

# ...
    steps:
    - name: Configure AWS Credentials (using secrets)
      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: ${{ env.AWS_REGION }}
# ...

อย่างไรก็ตาม การใช้ OIDC (OpenID Connect) เป็นวิธีการที่ปลอดภัยกว่ามากในการจัดการ AWS Credentials ใน GitHub Actions เนื่องจากไม่จำเป็นต้องจัดเก็บ Static Credential ใน GitHub Secrets ครับ

เทคนิคขั้นสูงสำหรับ GitHub Actions

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

Matrix Builds

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

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20] # Test with Node.js 18 and 20

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm install
    - run: npm test

การทำ Caching Dependencies

การ Cache Dependencies เช่น node_modules, Maven repository, หรือ pip cache สามารถลดเวลาในการติดตั้ง Dependency ได้อย่างมากครับ

steps:
  - uses: actions/checkout@v4
  - name: Cache Node.js modules
    uses: actions/cache@v4
    with:
      path: ~/.npm # Path to cache
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} # Cache key
      restore-keys: |
        ${{ runner.os }}-node-
  - name: Install dependencies
    run: npm install

ในตัวอย่าง CI Pipeline เราได้ใช้ cache: 'npm' ใน actions/setup-node@v4 ซึ่งเป็นการทำ Caching ที่ง่ายและมีประสิทธิภาพสำหรับ Node.js อยู่แล้วครับ

Reusable Workflows

ถ้าคุณมีหลาย Repository ที่ใช้ Workflow คล้ายๆ กัน คุณสามารถสร้าง Reusable Workflow เพื่อหลีกเลี่ยงการเขียนโค้ดซ้ำซ้อนได้ครับ

# .github/workflows/reusable-build.yml
name: Reusable Build

on:
  workflow_call: # Callable by other workflows
    inputs:
      node-version:
        required: true
        type: string
    secrets:
      NPM_TOKEN:
        required: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: 'npm'
      - run: npm install
      - run: npm run build

วิธีเรียกใช้:

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

on: [push]

jobs:
  call-build-workflow:
    uses: ./.github/workflows/reusable-build.yml # Call the reusable workflow
    with:
      node-version: '20'
    secrets:
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Self-Hosted Runners

เมื่อคุณต้องการควบคุมสภาพแวดล้อมการรัน Workflow อย่างสมบูรณ์, มีข้อจำกัดด้านเครือข่ายภายในองค์กร, หรือต้องการใช้ Hardware ที่มีประสิทธิภาพสูงกว่า GitHub-hosted runners คุณสามารถตั้งค่า Self-Hosted Runners ได้ครับ

คุณจะต้องติดตั้ง GitHub Actions Runner application บนเซิร์ฟเวอร์ของคุณ (Linux, Windows, macOS) และลงทะเบียน Runner กับ Repository หรือ Organization ของคุณครับ จากนั้นใน Workflow คุณเพียงแค่ระบุ runs-on: self-hosted หรือใช้ Label ที่กำหนดเอง เช่น runs-on: [self-hosted, linux, x64, custom-label] ครับ

GitHub Environments และ Protection Rules

GitHub Environments ช่วยให้คุณกำหนดสภาพแวดล้อมการ Deploy (เช่น Development, Staging, Production) และใช้ Protection Rules เพื่อเพิ่มความปลอดภัยและความมั่นใจในการ Deploy ครับ

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

  • ต้องมีการอนุมัติด้วยตนเอง (Manual Approval) ก่อนที่จะ Deploy ไปยัง Environment นั้นๆ
  • รอระยะเวลาหนึ่ง (Wait Timer) ก่อนที่จะเริ่ม Deploy
  • จำกัด Branch ที่สามารถ Deploy ไปยัง Environment นั้นได้

การตั้งค่าเหล่านี้สามารถทำได้ที่ Settings > Environments ใน Repository ของคุณครับ และใน Workflow ให้ระบุ environment: <your-environment-name> ครับ

การตรวจสอบและแจ้งเตือน

การตรวจสอบสถานะของ Workflow และการแจ้งเตือนเมื่อเกิดข้อผิดพลาดเป็นสิ่งสำคัญครับ

  • GitHub UI: หน้า Actions ของ GitHub แสดงสถานะของทุก Workflow run และรายละเอียดของแต่ละ Job และ Step ครับ
  • Badges: คุณสามารถเพิ่ม Workflow status badges ใน README.md เพื่อแสดงสถานะล่าสุดของ CI/CD ได้ครับ
  • Integrations: ใช้ Actions สำหรับส่งการแจ้งเตือนไปยัง Slack, Microsoft Teams, หรืออีเมลเมื่อ Workflow สำเร็จหรือล้มเหลวครับ

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

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

  • เริ่มต้นจากสิ่งเล็กๆ: อย่าพยายาม Automate ทุกอย่างในครั้งเดียว เริ่มจาก Workflow CI ง่ายๆ ก่อน จากนั้นค่อยๆ เพิ่ม CD และฟีเจอร์ขั้นสูงอื่นๆ ครับ
  • แยก Workflow ตามความรับผิดชอบ: แทนที่จะมี Workflow ขนาดยักษ์ ให้แยกเป็น Workflow ย่อยๆ เช่น ci.yml สำหรับ Build/Test และ cd.yml สำหรับ Deploy ครับ หรือใช้ Reusable Workflows ครับ
  • ใช้ Secrets อย่างปลอดภัย: ไม่เก็บข้อมูลที่ละเอียดอ่อนในโค้ดหรือไฟล์ Workflow ใช้ GitHub Secrets หรือ OIDC เสมอครับ
  • ทดสอบ Workflow ของคุณ: ทดสอบ Workflow ของคุณเหมือนที่คุณทดสอบโค้ดแอปพลิเคชันของคุณครับ Commit การเปลี่ยนแปลงเล็กๆ น้อยๆ เพื่อดูว่า Workflow ทำงานถูกต้องหรือไม่ครับ
  • ใช้ Actions ที่เป็นที่รู้จักและได้รับการดูแล: เลือกใช้ Actions จาก GitHub Marketplace ที่มีดาวเยอะๆ หรือจากผู้พัฒนาที่น่าเชื่อถือ เพื่อลดความเสี่ยงด้านความปลอดภัยและมั่นใจในการบำรุงรักษาครับ
  • กำหนด Version ของ Actions: ระบุเวอร์ชันของ Actions ที่คุณใช้ (เช่น @v4 หรือ @specific_sha) เพื่อให้มั่นใจว่า Workflow ของคุณทำงานได้สม่ำเสมอและไม่ได้รับผลกระทบจากการเปลี่ยนแปลงในเวอร์ชันใหม่ของ Action นั้นๆ ครับ
  • ตรวจสอบ Log อย่างสม่ำเสมอ: หาก Workflow ล้มเหลว ให้ตรวจสอบ Log อย่างละเอียดเพื่อหาสาเหตุของปัญหาครับ
  • ทำ Code Review สำหรับ Workflow: ปฏิบัติต่อไฟล์ Workflow เหมือนกับโค้ดแอปพลิเคชัน โดยให้มีการ Code Review ก่อน Merge เข้า Branch หลักครับ
  • พิจารณาการใช้ Environments: สำหรับ Production Deployment ควรใช้ GitHub Environments พร้อม Protection Rules เพื่อเพิ่มความปลอดภัยและควบคุมการ Deploy ครับ
  • เปิดใช้งาน Dependabot: ให้ Dependabot ช่วยคุณอัปเดต Dependency ของ Actions และไลบรารีต่างๆ เพื่อรักษาความปลอดภัยและประสิทธิภาพครับ อ่านเพิ่มเติมเกี่ยวกับ Dependabot

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

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

คุณสมบัติ GitHub Actions Jenkins GitLab CI/CD CircleCI
รูปแบบการใช้งาน YAML-based, Integrated with GitHub Script-based, UI-based, Plugin-heavy YAML-based, Integrated with GitLab YAML-based, Cloud-native
การติดตั้ง/ตั้งค่า ง่ายมาก, พร้อมใช้งานทันทีบน GitHub ซับซ้อน, ต้องติดตั้งและดูแลเซิร์ฟเวอร์เอง (Self-hosted) ในตัวสำหรับ GitLab, ติดตั้ง Runner ได้ง่าย ง่าย, SaaS-based, ตั้งค่าผ่าน UI/CLI
Hosted Runners มี (Ubuntu, Windows, macOS) ไม่มี (ต้องจัดการเองทั้งหมด) มีสำหรับ GitLab.com มี (Linux, macOS, Windows)
Self-Hosted Runners มี หลัก (เน้น Self-hosted) มี มี
การจัดการ Secrets GitHub Secrets, OIDC Creds Plugin, Environment Variables CI/CD Variables, Vault Contexts, Environment Variables
ราคา ฟรีสำหรับ Public Repos, มีโควต้าสำหรับ Private Repos (จ่ายเพิ่มตามการใช้งาน) ฟรี (Open-source), มีค่าใช้จ่ายสำหรับ Hardware/Infrastructure ฟรีสำหรับ Public Repos และ Tier ฟรีของ Private Repos, จ่ายเพิ่มสำหรับ Enterprise ฟรี Tier, จ่ายเพิ่มตามการใช้งาน
ความสามารถในการขยาย Marketplace Actions, Reusable Workflows, Self-hosted runners Plugins จำนวนมาก, Distributed Builds Templates, Parent-Child Pipelines, Self-hosted runners Orbs, Self-hosted runners
การผสานรวม ลึกซึ้งกับ GitHub Ecosystem หลากหลาย (ผ่าน Plugins) ลึกซึ้งกับ GitLab Ecosystem หลากหลาย (ผ่าน Orbs)
ความง่ายในการใช้งาน สูง (สำหรับผู้ใช้ GitHub) ปานกลางถึงต่ำ (ต้องเรียนรู้เยอะ) สูง (สำหรับผู้ใช้ GitLab) สูง
ชุมชน เติบโตเร็ว, GitHub Community ใหญ่มาก, มีมานาน ใหญ่, GitLab Community ปานกลาง

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

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

GitHub Actions มี Tier ฟรีสำหรับทั้ง Public และ Private Repositories ครับ สำหรับ Public Repos จะมีจำนวนนาทีและพื้นที่จัดเก็บ Artifacts ให้ฟรีไม่จำกัดครับ ส่วน Private Repos จะมีโควต้าฟรีต่อเดือน (เช่น 2,000 นาทีและ 500MB สำหรับบัญชีฟรี) หากใช้งานเกินโควต้า จะมีค่าใช้จ่ายตามการใช้งานครับ

2. ถ้า Workflow ล้มเหลว ผมจะรู้ได้อย่างไรครับ?

เมื่อ Workflow ล้มเหลว GitHub จะแสดงสถานะ Failed ในหน้า Actions ของ Repository ครับ คุณสามารถคลิกเข้าไปดูรายละเอียดของ Job และ Step ที่ล้มเหลว พร้อม Log ข้อผิดพลาดได้ครับ นอกจากนี้ คุณยังสามารถตั้งค่าการแจ้งเตือนผ่านอีเมล, Slack, หรือเครื่องมืออื่นๆ ได้ด้วย Actions ที่เกี่ยวข้องครับ

3. ผมจะจัดการกับ Environment Variables และ Secrets ใน GitHub Actions ได้อย่างไรครับ?

สำหรับข้อมูลที่ไม่ละเอียดอ่อน เช่น ชื่อ Region, ชื่อ Docker Image คุณสามารถกำหนดเป็น Environment Variables ได้โดยใช้คีย์เวิร์ด env ใน Workflow ครับ ส่วนข้อมูลที่ละเอียดอ่อน เช่น API Keys, Passwords, Access Tokens ควรใช้ GitHub Secrets ครับ โดยไปที่ Settings > Secrets and variables > Actions ของ Repository หรือ Organization เพื่อเพิ่ม Secret ครับ จากนั้นเรียกใช้ใน Workflow ด้วย ${{ secrets.MY_SECRET_NAME }} ครับ

4. ผมสามารถ Deploy ไปยังหลายๆ Environment (เช่น Staging, Production) ได้อย่างไรครับ?

คุณสามารถทำได้หลายวิธีครับ:

  • แยก Workflow: สร้าง Workflow แยกกันสำหรับแต่ละ Environment (เช่น cd-staging.yml และ cd-production.yml) และกำหนด Trigger หรือ Protection Rules ที่แตกต่างกันครับ
  • ใช้ Conditions: ใช้ if Condition ใน Job หรือ Step เพื่อ Deploy ไปยัง Environment ที่ต่างกันตาม Branch หรือ Input ที่เข้ามาครับ
  • ใช้ GitHub Environments: กำหนด Environments ใน GitHub Settings (เช่น Staging, Production) และใช้ Protection Rules (เช่น Manual Approval) และเชื่อมโยง Job ใน Workflow กับ Environment นั้นๆ ครับ

วิธีที่แนะนำคือการใช้ GitHub Environments เพื่อเพิ่มความปลอดภัยและการควบคุมครับ

5. GitHub Actions รองรับภาษาและแพลตฟอร์มอะไรบ้างครับ?

GitHub Actions รองรับภาษาและแพลตฟอร์มแทบทุกชนิดครับ เนื่องจาก Runner เป็น Virtual Machine หรือ Container คุณสามารถติดตั้งและรันเครื่องมือใดๆ ก็ได้ครับ มี Actions สำหรับภาษาและแพลตฟอร์มยอดนิยมมากมาย เช่น Node.js, Python, Java, .NET, Go, PHP, Ruby รวมถึงการ Deploy ไปยัง Cloud Provider หลักๆ อย่าง AWS, Azure, Google Cloud และ Kubernetes ครับ

สรุปและ Call-to-Action

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

ด้วยความสามารถในการผสานรวมกับ GitHub ได้อย่างลึกซึ้ง, Marketplace ที่เต็มไปด้วย Actions มากมาย, และความยืดหยุ่นในการปรับแต่ง Workflow ทำให้ GitHub Actions เป็นตัวเลือกที่ยอดเยี่ยมสำหรับโปรเจกต์ทุกขนาด ตั้งแต่โปรเจกต์ส่วนตัวไปจนถึง Enterprise Applications เลยครับ

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

หากคุณสนใจเกี่ยวกับเทคนิคการพัฒนาและ Deployment อื่นๆ สามารถ อ่านบทความเพิ่มเติม ได้เลยครับ และถ้าคุณพร้อมที่จะยกระดับการพัฒนาซอฟต์แวร์ของคุณไปอีกขั้น ลองสำรวจบริการ SiamLancard.com ที่เกี่ยวข้องกับ DevOps และ Cloud Computing ของเราได้เลยครับ

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

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