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

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

สารบัญ

• CI/CD Pipeline คืออะไร? และทำไมถึงสำคัญ?
  • Continuous Integration (CI)
  • Continuous Delivery (CD)
  • Continuous Deployment (CD)
• ทำความรู้จักกับ GitHub Actions
  • ส่วนประกอบสำคัญของ GitHub Actions
  • ทำไมต้องเลือก GitHub Actions?
• เริ่มต้นสร้าง Workflow ด้วย GitHub Actions
  • โครงสร้างไฟล์ Workflow
  • Event ที่กระตุ้น Workflow
  • Jobs, Steps และ Actions
  • Runners: ที่ทำงานของ Workflow
• ตัวอย่างการสร้าง CI Pipeline (สำหรับ Node.js Project)
  • ออกแบบ CI Workflow
  • ไฟล์ .github/workflows/ci.yml
  • อธิบาย CI Workflow อย่างละเอียด
• ตัวอย่างการสร้าง CD Pipeline (Deploy ไปยัง AWS S3)
  • ออกแบบ CD Workflow
  • การจัดการ Secrets สำหรับการ Deploy
  • ไฟล์ .github/workflows/cd.yml
  • อธิบาย CD Workflow อย่างละเอียด
• แนวคิดและเทคนิคขั้นสูงใน GitHub Actions
  • Matrix Builds
  • การแคช Dependencies
  • Reusable Workflows
  • การใช้ Environments และ Manual Approvals
  • หลักปฏิบัติที่ดีด้านความปลอดภัย
• ความท้าทายที่พบบ่อยและแนวทางแก้ไข
• คำถามที่พบบ่อย (FAQ)
• สรุปและ Call-to-Action

CI/CD Pipeline คืออะไร? และทำไมถึงสำคัญ?

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

Continuous Integration (CI)

Continuous Integration (CI) คือการที่นักพัฒนาหลายคนรวมโค้ดที่เขียนเสร็จแล้วเข้าสู่ Shared Repository (เช่น GitHub) บ่อยครั้งในแต่ละวันครับ โดยปกติแล้วการรวมโค้ดแต่ละครั้งจะมีการรันชุดการทดสอบอัตโนมัติ (Automated Tests) เพื่อตรวจสอบว่าโค้ดใหม่ที่รวมเข้ามาไม่ได้ทำให้ระบบเดิมเสียหายครับ

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

• ตรวจจับข้อผิดพลาดได้เร็ว: การรวมโค้ดบ่อยครั้งและทดสอบอัตโนมัติช่วยให้สามารถระบุและแก้ไขบั๊กได้ตั้งแต่เนิ่นๆ ครับ
• ลดความขัดแย้งของโค้ด: การรวมโค้ดบ่อยๆ ทำให้การเปลี่ยนแปลงมีขนาดเล็ก ช่วยลดโอกาสที่จะเกิด Merge Conflicts ขนาดใหญ่
• ปรับปรุงคุณภาพโค้ด: การรัน Linting และ Static Analysis ใน CI ช่วยรักษาสไตล์และคุณภาพของโค้ดให้สอดคล้องกันครับ
• สร้างความมั่นใจ: ทีมมีความมั่นใจมากขึ้นว่าโค้ดเบสอยู่ในสถานะที่พร้อมใช้งานอยู่เสมอ

Continuous Delivery (CD)

Continuous Delivery (CD) เป็นขั้นตอนต่อจาก CI ครับ เมื่อโค้ดผ่านกระบวนการ CI และการทดสอบทั้งหมดแล้ว โค้ดจะถูกบรรจุเป็น Artifact ที่พร้อมสำหรับการ Deploy (เช่น Docker image, ไฟล์ .jar, ไฟล์ .zip) และพร้อมที่จะถูก Deploy ไปยังสภาพแวดล้อมต่างๆ เช่น Staging หรือ Production ได้ตลอดเวลา แต่การ Deploy ไปยัง Production อาจยังต้องมีการอนุมัติหรือการตัดสินใจด้วยคนครับ

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

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

Continuous Deployment (CD)

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

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

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

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

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

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

การทำความเข้าใจส่วนประกอบเหล่านี้เป็นสิ่งสำคัญในการสร้าง Workflow ที่มีประสิทธิภาพครับ

• Workflow: คือกระบวนการอัตโนมัติที่คุณกำหนดขึ้นมา เป็นไฟล์ YAML ที่อยู่ในไดเรกทอรี .github/workflows/ ภายใน Repository ของคุณครับ Workflow สามารถถูกกระตุ้นได้ด้วย Event ต่างๆ เช่น การ Push โค้ด, การเปิด Pull Request, การรันตามกำหนดเวลา หรือการเรียกใช้ด้วยมือครับ
• Event: คือกิจกรรมที่เกิดขึ้นใน Repository ของคุณ (หรือภายนอก) ที่กระตุ้นให้ Workflow ทำงานครับ ตัวอย่างเช่น push, pull_request, schedule, workflow_dispatch ครับ
• Job: คือชุดของ Steps ที่รันอยู่บน Runner เดียวกันครับ แต่ละ Job จะรันในสภาพแวดล้อมที่แยกจากกัน และสามารถรันแบบ Parallel (พร้อมกัน) หรือ Sequential (ตามลำดับ) ก็ได้ครับ
• Step: คือชุดของคำสั่ง (Commands) หรือ Action ที่จะถูกรันใน Job ครับ Step สามารถเป็น Shell Script (เช่น run: npm install) หรือ Action ที่นำกลับมาใช้ใหม่ได้ครับ
• Action: คือคำสั่งที่นำกลับมาใช้ใหม่ได้ที่ถูกสร้างขึ้นมาโดย GitHub, ชุมชน หรือบุคคลทั่วไปครับ Actions ช่วยให้คุณสามารถทำงานที่ซับซ้อนได้อย่างง่ายดายโดยไม่ต้องเขียนโค้ดเองทั้งหมดครับ เช่น actions/checkout@v4 สำหรับ Clone Repository หรือ actions/setup-node@v4 สำหรับติดตั้ง Node.js ครับ
• Runner: คือเซิร์ฟเวอร์ที่รัน Workflow ของคุณครับ GitHub Actions มี GitHub-hosted runners ที่รองรับระบบปฏิบัติการยอดนิยม (Ubuntu, Windows, macOS) พร้อมซอฟต์แวร์และเครื่องมือที่ติดตั้งมาให้แล้ว หรือคุณสามารถใช้ Self-hosted runners ของคุณเองก็ได้ครับ

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

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

จากตารางเปรียบเทียบจะเห็นได้ว่า GitHub Actions เหมาะสำหรับโปรเจกต์ที่ต้องการความรวดเร็วในการตั้งค่า ใช้งานง่าย และผสานรวมกับ GitHub ได้อย่างลงตัวครับ

เริ่มต้นสร้าง Workflow ด้วย GitHub Actions

การสร้าง Workflow ด้วย GitHub Actions เริ่มต้นจากการสร้างไฟล์ YAML ในไดเรกทอรี .github/workflows/ ของ Repository ของคุณครับ

โครงสร้างไฟล์ Workflow

ไฟล์ Workflow จะอยู่ในรูปแบบ YAML และมีโครงสร้างพื้นฐานดังนี้ครับ

name: ชื่อ Workflow ของคุณ
on: # Event ที่จะกระตุ้น Workflow นี้
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch: # อนุญาตให้รัน Workflow นี้ด้วยมือ

jobs: # ชุดของ Jobs ที่จะรัน
  build: # ชื่อ Job แรก
    runs-on: ubuntu-latest # Runner ที่ใช้
    steps: # ขั้นตอนต่างๆ ใน Job นี้
      - name: Checkout code # ชื่อ Step
        uses: actions/checkout@v4 # Action ที่นำมาใช้

      - name: Setup Node.js # ชื่อ Step
        uses: actions/setup-node@v4
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

  deploy: # ชื่อ Job ที่สอง
    needs: build # Job นี้จะรันหลังจาก Job 'build' เสร็จสิ้น
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: echo "Deploying..."

Event ที่กระตุ้น Workflow

Workflow สามารถถูกกระตุ้นได้ด้วย Event หลากหลายประเภทครับ:

• push: เมื่อมีการ Push โค้ดไปยัง Branch ที่กำหนด
• pull_request: เมื่อมีการสร้าง, อัปเดต, หรือปิด Pull Request
• schedule: รันตามกำหนดเวลา cron job (เช่น schedule: - cron: '0 0 * * *' สำหรับรันทุกวันเที่ยงคืน)
• workflow_dispatch: อนุญาตให้รัน Workflow ด้วยมือจากแท็บ Actions ใน GitHub
• repository_dispatch: กระตุ้น Workflow จาก Event ภายนอก Repository
• และอื่นๆ อีกมากมายครับ

Jobs, Steps และ Actions

• Jobs: ถูกกำหนดภายใต้คีย์ jobs: ครับ แต่ละ Job จะมีชื่อเฉพาะ (เช่น build, deploy) และสามารถกำหนดคุณสมบัติอื่นๆ ได้ เช่น runs-on, needs, env, timeout-minutes ครับ
• Steps: ถูกกำหนดภายใต้คีย์ steps: ภายในแต่ละ Job ครับ แต่ละ Step จะรันตามลำดับที่กำหนดไว้ครับ
• Actions: เป็นองค์ประกอบพื้นฐานของ Step ครับ คุณสามารถใช้ Actions สำเร็จรูปจาก GitHub Marketplace (เช่น actions/checkout@v4) หรือสร้าง Custom Action ของคุณเองก็ได้ครับ Actions ช่วยให้ Workflow มีความยืดหยุ่นและนำกลับมาใช้ใหม่ได้ครับ

Runners: ที่ทำงานของ Workflow

GitHub Actions ใช้ “Runner” เป็น Environment สำหรับรัน Workflow ของคุณครับ

• GitHub-hosted runners: เป็น Runner ที่ GitHub จัดเตรียมและดูแลให้ครับ มีให้เลือกทั้ง Ubuntu, Windows, และ macOS พร้อมซอฟต์แวร์และเครื่องมือที่จำเป็นติดตั้งมาให้แล้ว เหมาะสำหรับโปรเจกต์ส่วนใหญ่ครับ (เช่น runs-on: ubuntu-latest)
• Self-hosted runners: คุณสามารถติดตั้ง Runner บน Server ของคุณเองได้ครับ ซึ่งมีประโยชน์ในกรณีที่คุณต้องการ Environment ที่กำหนดเอง, ทรัพยากรเฉพาะ, หรือเข้าถึงเครือข่ายภายในองค์กรครับ (เช่น runs-on: self-hosted)

ตัวอย่างการสร้าง CI Pipeline (สำหรับ Node.js Project)

เราจะมาสร้าง CI Pipeline สำหรับโปรเจกต์ Node.js อย่างง่ายกันครับ โดย Pipeline นี้จะทำการ:

1. Checkout โค้ดจาก Repository
2. ติดตั้ง Node.js environment
3. ติดตั้ง Dependencies ของโปรเจกต์ (npm install)
4. รัน Linting เพื่อตรวจสอบคุณภาพโค้ด
5. รัน Automated Tests (npm test)
6. สร้าง Artifact (เช่น Build โปรเจกต์)

สมมติว่าคุณมีโปรเจกต์ Node.js ที่มี package.json, package-lock.json, และมีสคริปต์ test และ build ใน package.json ครับ

ออกแบบ CI Workflow

Workflow นี้จะถูกกระตุ้นเมื่อมีการ Push โค้ดไปยัง Branch main หรือมีการเปิด/อัปเดต Pull Request ที่ส่งไปยัง Branch main ครับ

ไฟล์ .github/workflows/ci.yml

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

name: Node.js CI Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch: # อนุญาตให้รันด้วยมือ

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # เพื่อให้ Git history ทั้งหมดถูก fetch มาด้วย (อาจจำเป็นสำหรับบางเครื่องมือ)

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

      - name: Install dependencies
        run: npm ci # 'npm ci' จะติดตั้ง dependencies ตาม package-lock.json ซึ่งเหมาะสำหรับ CI/CD

      - name: Run ESLint
        run: npm run lint # สมมติว่ามี script 'lint' ใน package.json
        continue-on-error: true # อนุญาตให้ CI ดำเนินต่อไปแม้ lint จะมีข้อผิดพลาด (แต่จะแสดง warning)

      - name: Run unit tests
        run: npm test # สมมติว่ามี script 'test' ใน package.json

      - name: Build project (e.g., frontend assets)
        run: npm run build --if-present # รัน build script ถ้ามี

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: my-app-build-artifact
          path: build/ # หรือโฟลเดอร์ผลลัพธ์จากการ build ของคุณ
          retention-days: 5 # เก็บ artifact ไว้ 5 วัน

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

• name: Node.js CI Pipeline: ตั้งชื่อ Workflow ให้เข้าใจง่ายครับ
• on:: กำหนด Event ที่จะกระตุ้น Workflow นี้
  • push: branches: - main: Workflow จะทำงานเมื่อมีการ Push โค้ดไปยัง Branch main ครับ
  • pull_request: branches: - main: Workflow จะทำงานเมื่อมีการเปิดหรืออัปเดต Pull Request ที่มีเป้าหมายเป็น Branch main ครับ
  • workflow_dispatch:: ช่วยให้คุณสามารถรัน Workflow นี้ด้วยมือจากแท็บ Actions ใน GitHub ได้ครับ
• jobs:: กำหนดชุดของ Job ต่างๆ ในที่นี้มี Job เดียวคือ build ครับ
  • build:: ชื่อ Job
  • runs-on: ubuntu-latest: กำหนดให้ Job นี้รันบน GitHub-hosted runner ที่เป็น Ubuntu เวอร์ชันล่าสุดครับ
  • steps:: กำหนดขั้นตอนต่างๆ ภายใน Job build
    • - name: Checkout repository code: Step แรกคือการ Checkout โค้ดจาก Repository ของคุณมายัง Runner ครับ
      • uses: actions/checkout@v4: ใช้ Action สำเร็จรูป checkout เวอร์ชัน 4
      • with: fetch-depth: 0: เป็นการตั้งค่าเพิ่มเติมที่บางครั้งจำเป็นสำหรับเครื่องมือที่ต้องการ Git history ทั้งหมด เช่น Semantic Release หรือ Conventional Commits ครับ
    • - name: Setup Node.js environment: ติดตั้ง Node.js Runtime ครับ
      • uses: actions/setup-node@v4: ใช้ Action setup-node เวอร์ชัน 4
      • with: node-version: '18': ระบุเวอร์ชันของ Node.js ที่ต้องการติดตั้ง
      • cache: 'npm': GitHub Actions สามารถแคช Dependencies ของ Package Managers (npm, yarn, pnpm) ได้ครับ การเปิดใช้งาน Cache จะช่วยลดเวลาในการติดตั้ง Dependencies ในการรัน Workflow ครั้งต่อๆ ไปได้มากครับ
    • - name: Install dependencies: ติดตั้ง Package Dependencies ที่ระบุใน package.json ครับ
      • run: npm ci: คำสั่ง npm ci (Clean Install) เป็นทางเลือกที่ดีกว่า npm install สำหรับ CI/CD เพราะมันจะติดตั้ง Dependencies ตาม package-lock.json อย่างเคร่งครัด ทำให้มั่นใจได้ว่า Dependencies ที่ติดตั้งจะเหมือนกันทุกครั้งครับ
    • - name: Run ESLint: รัน ESLint เพื่อตรวจสอบสไตล์และคุณภาพของโค้ดครับ
      • run: npm run lint: สมมติว่าคุณมีสคริปต์ "lint": "eslint . --ext .js,.jsx,.ts,.tsx" ใน package.json ครับ
      • continue-on-error: true: เป็นการตั้งค่าที่ระบุว่าแม้ Step นี้จะล้มเหลว (เช่น ESLint พบข้อผิดพลาด) Workflow ก็จะยังคงดำเนินต่อไปได้ แต่ Step นี้จะถูกทำเครื่องหมายเป็น “warning” ครับ คุณสามารถเอาออกได้หากต้องการให้ ESLint ที่ล้มเหลวทำให้ CI ล้มเหลวทันทีครับ
    • - name: Run unit tests: รัน Automated Tests ครับ
      • run: npm test: สมมติว่าคุณมีสคริปต์ "test": "jest" หรือ "test": "react-scripts test" ใน package.json ครับ
    • - name: Build project (e.g., frontend assets): สร้าง Artifact ของโปรเจกต์ครับ เช่น สำหรับโปรเจกต์ React, Vue, Angular ก็คือการ Build Frontend Assets ครับ
      • run: npm run build --if-present: คำสั่ง --if-present จะรันสคริปต์ build ถ้ามีอยู่ใน package.json และจะข้ามไปถ้าไม่มีครับ
    • - name: Upload build artifact: อัปโหลดผลลัพธ์จากการ Build เป็น Artifact ครับ Artifact คือไฟล์หรือโฟลเดอร์ที่สร้างขึ้นโดย Workflow ที่สามารถดาวน์โหลดได้หลังจาก Workflow เสร็จสิ้น มักใช้เพื่อส่งต่อผลลัพธ์ไปยัง Job อื่นๆ หรือเก็บไว้สำหรับ Deploy ในอนาคตครับ
      • uses: actions/upload-artifact@v4: ใช้ Action upload-artifact เวอร์ชัน 4
      • with: name: my-app-build-artifact: กำหนดชื่อของ Artifact
      • path: build/: ระบุพาธของโฟลเดอร์หรือไฟล์ที่ต้องการอัปโหลด (สมมติว่าผลลัพธ์จากการ Build อยู่ในโฟลเดอร์ build/)
      • retention-days: 5: กำหนดจำนวนวันที่ Artifact จะถูกเก็บไว้ก่อนที่จะถูกลบอัตโนมัติครับ

เมื่อคุณ Push ไฟล์ ci.yml นี้ไปยัง GitHub Repository ของคุณ GitHub Actions จะเริ่มทำงานทันทีครับ คุณสามารถดูสถานะการทำงานได้ที่แท็บ “Actions” ใน GitHub Repository ของคุณครับ หากทุกอย่างผ่าน คุณก็จะมี CI Pipeline ที่แข็งแกร่งพร้อมใช้งานแล้วครับ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการจัดการ Dependency Cache ใน GitHub Actions ลองดูที่นี่ครับ อ่านเพิ่มเติม

ตัวอย่างการสร้าง CD Pipeline (Deploy ไปยัง AWS S3)

หลังจากที่ CI Pipeline ของเราประสบความสำเร็จในการ Build โปรเจกต์แล้ว ขั้นตอนต่อไปคือการ Deploy ครับ เราจะสาธิตการสร้าง CD Pipeline เพื่อ Deploy เว็บไซต์ Static (เช่น เว็บไซต์ที่ Build ด้วย React, Vue, Angular) ไปยัง AWS S3 ครับ

ข้อกำหนดเบื้องต้น:

• คุณมี AWS Account
• คุณได้สร้าง S3 Bucket ที่กำหนดค่าเป็น Static Website Hosting ไว้แล้ว
• คุณได้สร้าง IAM User หรือ IAM Role ที่มีสิทธิ์ในการเขียนและลบไฟล์ใน S3 Bucket นั้น

ออกแบบ CD Workflow

Workflow นี้จะถูกกระตุ้นเมื่อมีการ Push โค้ดไปยัง Branch main และ CI Pipeline (Job build) เสร็จสิ้นและประสบความสำเร็จครับ

การจัดการ Secrets สำหรับการ Deploy

การ Deploy ไปยัง Cloud Provider อย่าง AWS จำเป็นต้องใช้ข้อมูล Credentials ที่เป็นความลับครับ เราไม่ควร hardcode ข้อมูลเหล่านี้ลงในไฟล์ Workflow ครับ GitHub Actions มีฟีเจอร์สำหรับจัดการ Secrets โดยเฉพาะ

ไปที่ Repository ของคุณใน GitHub > Settings > Secrets and variables > Actions > New repository secret ครับ

สร้าง Secrets ดังนี้:

• AWS_ACCESS_KEY_ID: ใส่ Access Key ID ของ IAM User/Role ที่มีสิทธิ์ S3
• AWS_SECRET_ACCESS_KEY: ใส่ Secret Access Key ของ IAM User/Role นั้น
• AWS_REGION: ใส่ Region ของ AWS ที่คุณใช้ (เช่น ap-southeast-1 สำหรับสิงคโปร์)
• S3_BUCKET_NAME: ใส่ชื่อ S3 Bucket ของคุณ

เมื่อสร้างเสร็จแล้ว คุณสามารถอ้างอิงถึง Secrets เหล่านี้ใน Workflow ของคุณได้ด้วย ${{ secrets.SECRET_NAME }} ครับ

ไฟล์ .github/workflows/cd.yml

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

name: AWS S3 CD Pipeline

on:
  push:
    branches:
      - main
  workflow_dispatch: # อนุญาตให้รันด้วยมือ

env:
  # กำหนด Environment variables ที่ใช้ร่วมกันทั้ง Workflow
  AWS_REGION: ${{ secrets.AWS_REGION }}
  S3_BUCKET: ${{ secrets.S3_BUCKET_NAME }}
  BUILD_ARTIFACT_NAME: my-app-build-artifact # ชื่อเดียวกับที่ใช้ใน CI workflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: build # Job นี้จะรันหลังจาก Job 'build' จาก CI workflow เสร็จสิ้น

    # กำหนด Environment สำหรับ Job นี้ (ถ้าต้องการ)
    # environment: production # สามารถใช้ environments เพื่อกำหนด Policies และ Manual Approvals ได้

    steps:
      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: build_output # ดาวน์โหลด artifact ไปยังโฟลเดอร์นี้

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

      - name: Deploy to S3
        run: |
          aws s3 sync build_output/ ${{ env.S3_BUCKET }} --delete
          aws cloudfront create-invalidation --distribution-id YOUR_CLOUDFRONT_DISTRIBUTION_ID --paths "/*" || true # ล้าง CloudFront cache ถ้ามี

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

หมายเหตุ: อย่าลืมแทนที่ YOUR_CLOUDFRONT_DISTRIBUTION_ID ด้วย ID ของ CloudFront Distribution ของคุณ หากคุณใช้ CloudFront ด้วยครับ หากไม่ได้ใช้ ก็สามารถลบ Step นั้นออกได้ครับ

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

• name: AWS S3 CD Pipeline: ตั้งชื่อ Workflow
• on:: กำหนด Event ที่จะกระตุ้น Workflow นี้
  • push: branches: - main: Workflow จะทำงานเมื่อมีการ Push โค้ดไปยัง Branch main
  • workflow_dispatch:: อนุญาตให้รันด้วยมือ
• env:: กำหนด Environment Variables ที่สามารถใช้ได้ทั่วทั้ง Workflow
  • AWS_REGION, S3_BUCKET, BUILD_ARTIFACT_NAME: ดึงค่ามาจาก Secrets หรือกำหนดค่าคงที่
• jobs::
  • deploy:: ชื่อ Job
  • runs-on: ubuntu-latest: รันบน Ubuntu runner
  • needs: build: Job นี้จะรันก็ต่อเมื่อ Job ชื่อ build (จากไฟล์ ci.yml) เสร็จสิ้นและประสบความสำเร็จแล้วเท่านั้นครับ นี่คือวิธีที่เราเชื่อมโยง CI และ CD Pipeline เข้าด้วยกัน
  • steps::
    • - name: Download build artifact: ดาวน์โหลด Artifact ที่ถูกอัปโหลดไว้ใน CI Pipeline
      • uses: actions/download-artifact@v4: ใช้ Action download-artifact
      • with: name: ${{ env.BUILD_ARTIFACT_NAME }}: ระบุชื่อ Artifact ที่ต้องการดาวน์โหลด
      • path: build_output: ระบุโฟลเดอร์ปลายทางที่จะเก็บ Artifact ที่ดาวน์โหลดมาครับ
    • - name: Configure AWS Credentials: กำหนดค่า Credentials สำหรับการเข้าถึง AWS
      • uses: aws-actions/configure-aws-credentials@v4: ใช้ Action configure-aws-credentials ซึ่งเป็น Action อย่างเป็นทางการจาก AWS
      • with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}: ดึง Access Key ID จาก Repository Secret
      • aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}: ดึง Secret Access Key จาก Repository Secret
      • aws-region: ${{ env.AWS_REGION }}: ดึง AWS Region จาก Environment Variable ที่เรากำหนดไว้ด้านบน
      • Action นี้จะตั้งค่า Environment Variables ที่จำเป็นเพื่อให้คำสั่ง aws cli สามารถทำงานได้ครับ
    • - name: Deploy to S3: ทำการ Deploy ไฟล์ไปยัง S3 Bucket
      • run: |: ใช้ Multi-line command
      • aws s3 sync build_output/ s3://${{ env.S3_BUCKET }} --delete: ใช้คำสั่ง AWS CLI s3 sync เพื่อซิงค์เนื้อหาจากโฟลเดอร์ build_output/ ไปยัง S3 Bucket ของคุณครับ
        • --delete: จะลบไฟล์ใน S3 Bucket ที่ไม่มีอยู่ในโฟลเดอร์ต้นทาง (build_output/) ออกด้วยครับ เพื่อให้มั่นใจว่า S3 Bucket มีแต่ไฟล์เวอร์ชันล่าสุดเท่านั้น
      • aws cloudfront create-invalidation ... || true: คำสั่งนี้จะล้าง CloudFront Cache หากคุณใช้ CloudFront เพื่อให้บริการเว็บไซต์จาก S3 ครับ การล้าง Cache จำเป็นเพื่อให้ผู้ใช้เห็นเนื้อหาเวอร์ชันใหม่ทันที คำสั่ง || true จะทำให้ Step นี้ไม่ล้มเหลวแม้ว่าคำสั่ง CloudFront จะมีปัญหา (เช่น ถ้ายังไม่มี CloudFront Distribution ID) ครับ
    • - name: Invalidate CloudFront (Optional - if using CloudFront): Step แยกออกมาเพื่อให้ชัดเจนในการ Invalidate CloudFront (หากคุณใช้)
      • if: success(): จะรัน Step นี้ก็ต่อเมื่อ Step ก่อนหน้าทั้งหมดสำเร็จเท่านั้นครับ
      • env: CLOUDFRONT_DISTRIBUTION_ID: YOUR_CLOUDFRONT_DISTRIBUTION_ID: กำหนด Environment Variable เฉพาะสำหรับ Step นี้

เมื่อคุณ Push ไฟล์ cd.yml นี้ไปยัง GitHub Actions จะตรวจจับการเปลี่ยนแปลงและหาก CI Pipeline ผ่าน Job deploy ก็จะเริ่มทำงานครับ คุณสามารถตรวจสอบได้ว่าไฟล์ของคุณถูกอัปโหลดไปยัง S3 Bucket เรียบร้อยแล้วครับ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการ Deploy ด้วย GitHub Actions ไปยัง AWS ลองดูที่นี่ครับ อ่านเพิ่มเติม

แนวคิดและเทคนิคขั้นสูงใน GitHub Actions

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

Matrix Builds

Matrix Builds ช่วยให้คุณสามารถรัน Job เดียวกันหลายๆ ครั้ง โดยมีการเปลี่ยนแปลงค่าของ Environment Variables หรือเวอร์ชันของ Runtime ครับ มีประโยชน์มากสำหรับการทดสอบโปรเจกต์ของคุณกับ Node.js หลายเวอร์ชัน, Python หลายเวอร์ชัน, หรือระบบปฏิบัติการที่แตกต่างกันครับ

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node-version: ['16', '18', '20']

    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test

Workflow นี้จะสร้าง 6 Jobs (2 OS * 3 Node.js versions) และรันพร้อมกัน ทำให้การทดสอบครอบคลุมและรวดเร็วขึ้นครับ

การแคช Dependencies

การติดตั้ง Dependencies เช่น npm install, pip install, หรือ composer install มักใช้เวลานานครับ GitHub Actions มี Action สำหรับแคช Dependencies เพื่อลดเวลาในการรัน Workflow ครับ

      - name: Cache Node.js modules
        uses: actions/cache@v4
        with:
          path: ~/.npm # หรือ ~/.cache/pip, ~/.composer
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

Action actions/setup-node@v4 ที่เราใช้ไปก่อนหน้านี้ก็มีพารามิเตอร์ cache: 'npm' ที่ช่วยจัดการการแคชให้โดยอัตโนมัติ ซึ่งสะดวกและแนะนำมากกว่าครับ

Reusable Workflows

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

ตัวอย่าง: reusable-build.yml (ใน .github/workflows/)

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

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
    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 }}
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: my-app-build-artifact
          path: build/

วิธีเรียกใช้: main-ci.yml (ใน .github/workflows/)

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

on:
  push:
    branches:
      - main

jobs:
  call-build:
    uses: ./.github/workflows/reusable-build.yml # เรียกใช้ Reusable Workflow จากใน repo เดียวกัน
    with:
      node-version: '18'
    secrets: inherit # ส่งต่อ secrets ทั้งหมด
    outputs:
      build-status: ${{ jobs.call-build.outputs.build-status }}

  deploy:
    needs: call-build
    if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' && needs.call-build.outputs.build-status == 'success' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying after successful build..."

Reusable Workflows ช่วยให้คุณสามารถสร้าง Library ของขั้นตอน CI/CD ที่นำกลับมาใช้ใหม่ได้ทั่วทั้งองค์กรของคุณครับ

การใช้ Environments และ Manual Approvals

GitHub Actions มีฟีเจอร์ Environments ที่ช่วยให้คุณสามารถกำหนดกฎและ Protection Rules สำหรับสภาพแวดล้อมการ Deploy ต่างๆ (เช่น Staging, Production) ได้ครับ ซึ่งรวมถึง:

• Required reviewers: กำหนดให้ต้องมีผู้ตรวจสอบอนุมัติการ Deploy ด้วยมือ
• Wait timer: กำหนดเวลาหน่วงก่อนการ Deploy
• Deployment branches: กำหนดว่าเฉพาะบาง Branch เท่านั้นที่สามารถ Deploy ไปยัง Environment นั้นได้

คุณสามารถกำหนด Environment ใน Job ได้ดังนี้:

jobs:
  deploy-to-production:
    runs-on: ubuntu-latest
    environment: production # อ้างถึง Environment ที่สร้างไว้ใน Settings
    needs: build
    steps:
      # ... deploy steps ...

เมื่อ Job นี้รัน ถ้า Environment ‘production’ มี Required reviewers คุณจะต้องไปอนุมัติด้วยมือในแท็บ Actions ก่อนที่ Job จะดำเนินต่อไปครับ

หลักปฏิบัติที่ดีด้านความปลอดภัย

• ใช้ Secrets อย่างระมัดระวัง: อย่า hardcode Credentials ลงในไฟล์ Workflow ใช้ GitHub Secrets เสมอครับ
• จำกัดสิทธิ์ของ Access Token: หากคุณจำเป็นต้องสร้าง Personal Access Token ให้จำกัดสิทธิ์ (Scopes) ให้แคบที่สุดเท่าที่จำเป็นครับ
• ใช้ OIDC (OpenID Connect) สำหรับ AWS/Azure/GCP: แทนการใช้ Access Key/Secret Key แบบเก่า คุณสามารถใช้ OIDC เพื่อให้ GitHub Actions สามารถรับ Temporary Credentials จาก Cloud Provider ได้โดยตรง ซึ่งปลอดภัยกว่ามากครับ อ่านเพิ่มเติมเกี่ยวกับ OIDC ใน GitHub Actions
• ระบุเวอร์ชันของ Actions: ใช้เวอร์ชันเฉพาะของ Actions (เช่น actions/checkout@v4) แทนที่จะใช้ @main หรือ @latest เพื่อหลีกเลี่ยงการเปลี่ยนแปลงที่อาจไม่คาดคิด
• ตรวจสอบ Actions ภายนอก: ก่อนใช้ Actions ที่มาจากภายนอก GitHub หรือ Marketplace ให้ตรวจสอบโค้ดและแหล่งที่มาให้มั่นใจในความปลอดภัยครับ

ความท้าทายที่พบบ่อยและแนวทางแก้ไข

• Workflow ล้มเหลวโดยไม่ทราบสาเหตุ:
  • แนวทางแก้ไข: ตรวจสอบ Log ของ Job ที่ล้มเหลวอย่างละเอียด GitHub Actions มี Log ที่ค่อนข้างละเอียดครับ บางครั้งปัญหาอาจเกิดจาก Dependencies ที่หายไป, คำสั่งผิดพลาด, หรือการตั้งค่า Environment ที่ไม่ถูกต้อง
• Workflow รันช้า:
  • แนวทางแก้ไข: ใช้ Caching สำหรับ Dependencies, แยก Job ที่ไม่เกี่ยวข้องให้รันแบบ Parallel, ใช้ Self-hosted runners หากต้องการทรัพยากรเฉพาะ, หรือ Optimize ขั้นตอนใน Job ครับ
• จัดการ Secrets จำนวนมาก:
  • แนวทางแก้ไข: ใช้ Organization Secrets หรือ Environment Secrets เพื่อรวม Secrets ที่ใช้ร่วมกัน, พิจารณาใช้ OIDC เพื่อลดการจัดการ Credentials โดยตรงครับ
• การ Deploy ที่ซับซ้อน (หลาย Environment, หลายภูมิภาค):
  • แนวทางแก้ไข: ใช้ Reusable Workflows เพื่อสร้างโมดูล Deploy ที่นำกลับมาใช้ใหม่ได้, ใช้ Environments และ Protection Rules เพื่อควบคุมการ Deploy ไปยังแต่ละ Environment ครับ
• ปัญหา Git LFS หรือ Large Repositories:
  • แนวทางแก้ไข: ใช้ fetch-depth: 1 สำหรับ actions/checkout หากไม่ต้องการ Git history ทั้งหมด หรือใช้ Self-hosted runners ที่มี Bandwidth สูงกว่าครับ

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

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

Q1: GitHub Actions ฟรีหรือไม่?
A1: GitHub Actions มี Free Tier ที่ค่อนข้าง generous ครับ สำหรับ Public Repositories คุณจะได้รับนาทีการใช้งานฟรีไม่จำกัด และสำหรับ Private Repositories คุณจะได้รับนาทีการใช้งานฟรีจำนวนหนึ่งในแต่ละเดือนครับ หากเกินกว่านั้นจะมีการคิดค่าใช้จ่ายตามนาทีที่ใช้งานครับ โดยปกติแล้ว สำหรับโปรเจกต์ส่วนตัวหรือทีมเล็กๆ Free Tier ก็เพียงพอแล้วครับ

Q2: ฉันสามารถรัน GitHub Actions บน Server ของตัวเองได้หรือไม่?
A2: ได้ครับ คุณสามารถตั้งค่า Self-hosted runners บน Server หรือเครื่องของคุณเองได้ ซึ่งมีประโยชน์หากคุณต้องการ Environment ที่กำหนดเอง, ติดตั้งซอฟต์แวร์เฉพาะ, หรือเข้าถึงเครือข่ายภายในองค์กรที่ไม่สามารถเข้าถึงได้จาก GitHub-hosted runners ครับ

Q3: ไฟล์ Workflow ต้องเป็น YAML เสมอไปหรือไม่?
A3: ใช่ครับ ไฟล์ Workflow ของ GitHub Actions ต้องเขียนด้วยภาษา YAML เท่านั้นครับ GitHub Actions ใช้ YAML เป็นภาษากำหนดค่า (Configuration Language) สำหรับ Workflow ของคุณครับ

Q4: การใช้ npm ci ใน CI/CD ดีกว่า npm install อย่างไร?
A4: npm ci (Clean Install) ถูกออกแบบมาเพื่อใช้ในสภาพแวดล้อม CI/CD โดยเฉพาะครับ มันจะลบโฟลเดอร์ node_modules ที่มีอยู่และติดตั้ง Dependencies ตาม package-lock.json อย่างเคร่งครัด ทำให้มั่นใจได้ว่าการติดตั้ง Dependencies จะเหมือนเดิมทุกครั้งและมีความน่าเชื่อถือสูงครับ ส่วน npm install อาจพยายามอัปเดต Dependencies หาก package-lock.json ไม่ตรงกับ package.json ซึ่งอาจนำไปสู่ปัญหาความไม่สอดคล้องกันได้ครับ

Q5: ฉันจะ Debug Workflow ที่ล้มเหลวได้อย่างไร?
A5: วิธีที่ดีที่สุดคือการดู Log ของ Job ที่ล้มเหลวในแท็บ Actions ของ Repository คุณครับ GitHub Actions จะให้ Log ที่ละเอียดสำหรับแต่ละ Step คุณสามารถขยาย Step ที่ล้มเหลวเพื่อดูข้อความ Error และ Stack Trace ได้ครับ นอกจากนี้ คุณยังสามารถเพิ่มคำสั่ง echo หรือ run: | ... เพื่อพิมพ์ค่าของ Environment Variables หรือผลลัพธ์ของคำสั่งต่างๆ ออกมาช่วยในการ Debug ได้ครับ

Q6: มีข้อจำกัดในการรัน Workflow หรือไม่?
A6: มีข้อจำกัดบางประการครับ เช่น ระยะเวลาสูงสุดของ Workflow (สูงสุด 6 ชั่วโมง), จำนวน Job สูงสุดใน Workflow (256 Jobs), จำนวน Step สูงสุดใน Job (1000 Steps) และข้อจำกัดด้านพื้นที่จัดเก็บ Artifact (สูงสุด 10 GB) ครับ ข้อจำกัดเหล่านี้มักจะไม่เป็นปัญหาสำหรับโปรเจกต์ส่วนใหญ่ครับ

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

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

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

อย่ารอช้าครับ! ลองนำความรู้ที่ได้จากบทความนี้ไปปรับใช้กับโปรเจกต์ของคุณดูวันนี้เลยครับ เริ่มต้นจาก CI Pipeline ง่ายๆ แล้วค่อยๆ เพิ่มความซับซ้อนของ CD Pipeline เมื่อคุณมีความคุ้นเคยมากขึ้นครับ หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์ หรือต้องการคำปรึกษาจากผู้เชี่ยวชาญด้าน DevOps และ Cloud Infrastructure ติดต่อ SiamLancard.com ได้เลยครับ ทีมงานของเราพร้อมให้ความช่วยเหลือคุณในการยกระดับกระบวนการพัฒนาซอฟต์แวร์ของคุณให้ก้าวหน้าไปอีกขั้นครับ