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

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

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

สารบัญ

• ทำความเข้าใจ CI/CD Pipeline คืออะไร และทำไมต้องใช้?
  • Continuous Integration (CI) คืออะไร?
  • Continuous Delivery (CD) และ Continuous Deployment (CD) คืออะไร?
  • ทำไม CI/CD จึงสำคัญต่อการพัฒนาซอฟต์แวร์?
• รู้จักกับ GitHub Actions: หัวใจสำคัญของ CI/CD บน GitHub
  • GitHub Actions คืออะไร?
  • ส่วนประกอบหลักของ GitHub Actions Workflow
  • ประโยชน์ของการใช้ GitHub Actions
• เตรียมความพร้อมก่อนสร้าง Pipeline
  • โครงสร้าง Repository และ Branching Strategy
  • ทำความเข้าใจ YAML เบื้องต้น
  • การจัดการ Secrets อย่างปลอดภัย
• ลงมือสร้าง CI Pipeline ด้วย GitHub Actions (ตัวอย่างที่ 1: Build & Test แอปพลิเคชัน Node.js)
  • โครงสร้างไฟล์ Workflow (.github/workflows/*.yml)
  • ตัวอย่าง CI Workflow สำหรับ Node.js
  • อธิบายแต่ละส่วนของ CI Workflow โดยละเอียด
• ขยายสู่ CD Pipeline: การ Deploy แอปพลิเคชันโดยอัตโนมัติ (ตัวอย่างที่ 2: Deploy Static Site ไปยัง GitHub Pages)
  • แนวคิดการ Deploy: Staging และ Production
  • ตัวอย่าง CD Workflow สำหรับ Static Site ไปยัง GitHub Pages
  • อธิบายแต่ละส่วนของ CD Workflow โดยละเอียด
• Advanced GitHub Actions Techniques & Best Practices
  • Matrix Builds
  • การทำ Caching Dependencies
  • Reusable Workflows และ Composite Actions
  • Environment Protection Rules และ Approvals
  • Self-hosted Runners
  • การใช้งาน GitHub Packages และ Artifacts
  • การมอนิเตอร์และแก้ไขปัญหา Workflow
  • หลักปฏิบัติที่ดีด้านความปลอดภัย (Security Best Practices)
• เปรียบเทียบ GitHub Actions กับ CI/CD Tools อื่นๆ
• กรณีศึกษา (Use Case Scenarios)
  • Web Application (Frontend/Backend)
  • Mobile App CI/CD
  • Infrastructure as Code (IaC) Deployment
• คำถามที่พบบ่อย (FAQ)
• สรุปและ Call-to-Action

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

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

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

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

• กระบวนการ CI จะประกอบด้วย:
  • การคอมไพล์/บิวด์โค้ด (Build): แปลง Source Code ให้เป็นไฟล์ที่สามารถรันได้ (เช่น .jar, .exe, Docker Image)
  • การรัน Unit Tests และ Integration Tests (Test): ตรวจสอบว่าโค้ดใหม่ที่ถูกรวมเข้ามาไม่ได้ทำให้ส่วนอื่น ๆ ของระบบเสียหาย
  • การวิเคราะห์โค้ด (Static Code Analysis): ตรวจหาข้อบกพร่องด้านความปลอดภัย, สไตล์โค้ด, หรือความซับซ้อนของโค้ด

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

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

หลังจากที่ CI ได้รับการดำเนินการเรียบร้อยแล้ว ขั้นตอนต่อไปคือ Continuous Delivery (CD) และ Continuous Deployment (CD) ครับ ทั้งสองคำนี้มักถูกใช้สลับกัน แต่มีความแตกต่างที่สำคัญ

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

  เป็นส่วนขยายของ CI ที่มุ่งเน้นไปที่การทำให้ซอฟต์แวร์พร้อมสำหรับการ Deploy ไปยังสภาพแวดล้อม Production ได้ตลอดเวลาครับ หลังจากที่โค้ดผ่านกระบวนการ CI ทั้งหมด (บิวด์, ทดสอบ) แล้ว ซอฟต์แวร์จะถูกแพ็กเกจและจัดเก็บไว้ในรูปแบบที่พร้อมสำหรับการ Deploy (เช่น Docker image, artifact file) แต่การ Deploy ไปยัง Production จะยังต้องอาศัยการตัดสินใจและดำเนินการด้วยมือ (manual approval) ครับ

• Continuous Deployment (CD) – การติดตั้งใช้งานอย่างต่อเนื่อง:

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

ความแตกต่างสำคัญคือ Continuous Delivery ต้องการการอนุมัติด้วยมือเพื่อ Deploy ไป Production ในขณะที่ Continuous Deployment ไม่ต้องการครับ

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

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

• เพิ่มความเร็วในการส่งมอบซอฟต์แวร์ (Faster Release Cycles):

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

• ปรับปรุงคุณภาพซอฟต์แวร์ (Improved Software Quality):

  การทดสอบอัตโนมัติในทุกขั้นตอนช่วยตรวจจับข้อบกพร่องได้ตั้งแต่เนิ่นๆ ทำให้มั่นใจได้ว่าโค้ดที่ถูก Deploy มีคุณภาพสูงและทำงานได้ตามที่คาดหวังครับ

• ลดความเสี่ยงและข้อผิดพลาด (Reduced Risk and Errors):

  กระบวนการที่เป็นอัตโนมัติช่วยลดโอกาสของข้อผิดพลาดที่เกิดจากมนุษย์ (human error) โดยเฉพาะอย่างยิ่งในขั้นตอนการ Deploy ที่มีความซับซ้อนครับ

• เพิ่มความร่วมมือในทีม (Enhanced Team Collaboration):

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

• ลดต้นทุน (Cost Reduction):

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

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

รู้จักกับ GitHub Actions: หัวใจสำคัญของ CI/CD บน GitHub

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

GitHub Actions คืออะไร?

GitHub Actions คือแพลตฟอร์มสำหรับระบบ Automation ที่ฝังอยู่ใน GitHub โดยตรงครับ มันช่วยให้คุณสามารถสร้าง workflows หรือชุดคำสั่งอัตโนมัติ ที่จะทำงานเมื่อมีเหตุการณ์ (events) บางอย่างเกิดขึ้นใน repository ของคุณ เช่น เมื่อมีคน push โค้ด, สร้าง pull request, หรือแม้แต่ตั้งเวลาไว้ครับ

ความสามารถหลักของ GitHub Actions คือการทำให้งานต่างๆ เช่น การบิวด์, การทดสอบ, การDeploy, หรือการจัดการโปรเจกต์ สามารถทำได้อย่างอัตโนมัติทั้งหมดบน GitHub โดยไม่จำเป็นต้องใช้บริการ CI/CD ภายนอกเลยครับ

ส่วนประกอบหลักของ GitHub Actions Workflow

Workflow ใน GitHub Actions ถูกกำหนดขึ้นมาในไฟล์ YAML ที่อยู่ในไดเรกทอรี .github/workflows/ ของ repository ของคุณครับ แต่ละ Workflow จะประกอบด้วยส่วนประกอบสำคัญดังนี้:

• Workflow: คือกระบวนการอัตโนมัติทั้งหมดที่ประกอบด้วยหนึ่งหรือหลาย Jobs ถูกกำหนดในไฟล์ YAML หนึ่งไฟล์
• Event: เหตุการณ์ที่กระตุ้นให้ Workflow เริ่มทำงาน เช่น push, pull_request, schedule, workflow_dispatch (manual trigger)
• Job: ชุดของ Steps ที่ถูกรันบน Runner เดียวกัน โดยแต่ละ Job จะทำงานแยกกันและสามารถรันพร้อมกัน (parallel) หรือเรียงลำดับ (sequential) กันได้
• Step: เป็นหน่วยย่อยที่สุดของ Job ที่ประกอบด้วยคำสั่งเดี่ยวๆ หรือ Action ที่จะดำเนินการ เช่น การรันคำสั่ง Shell script, การใช้ Action จาก Marketplace
• Action: แอปพลิเคชันที่สร้างไว้ล่วงหน้า (pre-built) ที่สามารถนำมาใช้ใน Steps ได้ Actions สามารถเป็นคำสั่ง Shell script, Docker container, หรือ JavaScript Application ก็ได้ครับ มี Action มากมายให้เลือกใช้ใน GitHub Marketplace
• Runner: เซิร์ฟเวอร์ที่ GitHub Actions ใช้ในการรัน Workflow ของคุณครับ GitHub มี GitHub-hosted runners ให้บริการ (Ubuntu, Windows, macOS) หรือคุณสามารถตั้งค่า self-hosted runners ของคุณเองก็ได้ครับ

ประโยชน์ของการใช้ GitHub Actions

การเลือกใช้ GitHub Actions ในการสร้าง CI/CD Pipeline มีข้อได้เปรียบหลายประการครับ

• ผสานรวมอย่างสมบูรณ์กับ GitHub (Native Integration):

  เนื่องจากเป็นส่วนหนึ่งของ GitHub ทำให้การตั้งค่าและการจัดการ Workflow เป็นไปอย่างราบรื่น ไม่ต้องเชื่อมต่อกับบริการภายนอกให้ยุ่งยากครับ

• Marketplace ที่หลากหลาย (Rich Ecosystem and Marketplace):

  มี Actions สำเร็จรูปมากมายใน GitHub Marketplace ที่ครอบคลุมงานเกือบทุกประเภท ไม่ว่าจะเป็นการบิวด์, ทดสอบ, Deploy ไปยัง Cloud Provider ต่างๆ, การแจ้งเตือน และอื่นๆ อีกมากมายครับ ทำให้การสร้าง Workflow ทำได้ง่ายและรวดเร็วขึ้น

• รองรับหลายภาษาและแพลตฟอร์ม (Multi-language and Multi-platform Support):

  รองรับภาษาโปรแกรมและเฟรมเวิร์กยอดนิยมเกือบทั้งหมด และสามารถรันบนระบบปฏิบัติการ Linux, Windows, และ macOS ได้ครับ

• กำหนดค่าได้ยืดหยุ่น (Flexible Configuration):

  ไฟล์ YAML ทำให้การกำหนดค่า Workflow มีความยืดหยุ่นสูง สามารถกำหนดเงื่อนไข, การรันแบบขนาน, การจัดการ Secrets ได้อย่างมีประสิทธิภาพ

• ควบคุม Self-hosted Runners ได้ (Self-hosted Runner Support):

  สำหรับองค์กรที่มีความต้องการพิเศษด้านความปลอดภัย, ทรัพยากร, หรือการเข้าถึงเครือข่ายภายใน สามารถตั้งค่า Self-hosted Runners ได้เองครับ

• ฟรีสำหรับ Public Repositories (Free for Public Repos):

  GitHub Actions สามารถใช้งานได้ฟรีอย่างไม่จำกัดสำหรับ Public Repositories และมีโควต้าการใช้งานฟรีสำหรับ Private Repositories ครับ

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

เตรียมความพร้อมก่อนสร้าง Pipeline

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

โครงสร้าง Repository และ Branching Strategy

โครงสร้างของ Repository และกลยุทธ์การแตก Branch (Branching Strategy) มีผลอย่างมากต่อประสิทธิภาพและความน่าเชื่อถือของ CI/CD Pipeline ครับ

• โครงสร้าง Repository:

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

• Branching Strategy:

  การเลือก Branching Strategy ที่เหมาะสมเป็นสิ่งสำคัญ เช่น Git Flow หรือ GitHub Flow การกำหนดว่า Workflow จะรันบน Branch ใดเมื่อใด จะช่วยควบคุมกระบวนการ CI/CD ได้อย่างมีประสิทธิภาพ

  • Git Flow: มักมี Branch หลักสองอันคือ master (สำหรับ Production) และ develop (สำหรับ integration) พร้อมด้วย Feature Branches และ Release Branches
  • GitHub Flow: เรียบง่ายกว่า โดยมี Branch main เป็น Branch หลัก และทำงานบน Feature Branches ที่แตกออกมาจาก main แล้ว Merge กลับเมื่อพร้อม

  โดยทั่วไปแล้ว:

  • CI (Build, Test) ควรจะรันทุกครั้งที่มีการ push หรือ pull_request ไปยัง Feature Branches หรือ Branch develop/main เพื่อตรวจจับปัญหาได้รวดเร็ว
  • CD (Deploy) มักจะรันเมื่อมีการ Merge โค้ดที่เสถียรแล้วเข้าสู่ Branch หลัก เช่น main หรือ master เพื่อ Deploy ไปยัง Production

ทำความเข้าใจ YAML เบื้องต้น

ไฟล์ Workflow ของ GitHub Actions ถูกเขียนด้วยภาษา YAML (YAML Ain’t Markup Language) ครับ หากคุณไม่คุ้นเคยกับ YAML นี่คือหลักการพื้นฐานที่คุณควรรู้:

• การเยื้อง (Indentation): YAML ใช้การเยื้อง (โดยใช้ Space เท่านั้น ห้ามใช้ Tab) เพื่อแสดงโครงสร้างของข้อมูล การเยื้องที่ถูกต้องมีความสำคัญมากครับ
• คีย์-ค่า (Key-Value Pairs): ข้อมูลจะอยู่ในรูปแบบ key: value เช่น name: My Workflow
• รายการ (Lists): ใช้เครื่องหมายขีดกลาง (-) เพื่อแสดงรายการ หรือ Array เช่น - Step 1, - Step 2
• คอมเมนต์ (Comments): ใช้เครื่องหมาย # เพื่อเพิ่มคอมเมนต์

# นี่คือตัวอย่างไฟล์ YAML เบื้องต้น
name: My Example Workflow # คีย์-ค่า
on: [push] # รายการของ Events
jobs:
  build: # ชื่อ Job
    runs-on: ubuntu-latest # คีย์-ค่า
    steps: # รายการของ Steps
      - name: Checkout code # คีย์-ค่าสำหรับชื่อ Step
        uses: actions/checkout@v4 # คีย์-ค่าสำหรับ Action ที่ใช้
      - name: Run a script
        run: echo "Hello, YAML!" # คีย์-ค่าสำหรับคำสั่งที่จะรัน

การเยื้องที่ผิดพลาดเป็นสาเหตุหลักที่ทำให้ Workflow ไม่ทำงาน ดังนั้นควรระมัดระวังในการเขียน YAML ให้ถูกต้องครับ

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

บ่อยครั้งที่ CI/CD Pipeline จำเป็นต้องใช้ข้อมูลที่ละเอียดอ่อน เช่น API Keys, Tokens, รหัสผ่าน หรือ Credentials สำหรับการ Deploy ไปยัง Cloud Providers ครับ การเก็บข้อมูลเหล่านี้ไว้ในไฟล์ Workflow โดยตรงเป็นเรื่องที่ไม่ปลอดภัยอย่างยิ่ง

GitHub Actions มีกลไกในการจัดการ Secrets ที่ช่วยให้คุณสามารถเก็บข้อมูลเหล่านี้ได้อย่างปลอดภัยและเรียกใช้ใน Workflow ได้โดยไม่ต้องเปิดเผยข้อมูลในโค้ดครับ

• วิธีการตั้งค่า Secrets:
  1. ไปที่ Repository ของคุณบน GitHub
  2. คลิกที่แท็บ Settings
  3. เลือก Secrets and variables > Actions
  4. คลิก New repository secret
  5. ป้อน Name ของ Secret (เช่น AWS_ACCESS_KEY_ID) และ Value ของ Secret นั้นๆ
• วิธีการเรียกใช้ Secrets ใน Workflow:

  คุณสามารถเข้าถึง Secrets ได้ผ่านออบเจกต์ secrets ใน Workflow ของคุณ โดยใช้ไวยากรณ์ ${{ secrets.SECRET_NAME }} ครับ

  jobs:
    deploy:
      runs-on: ubuntu-latest
      steps:
        - name: Deploy to AWS
          run: |
            aws configure set aws_access_key_id ${{ secrets.AWS_ACCESS_KEY_ID }}
            aws configure set aws_secret_access_key ${{ secrets.AWS_SECRET_ACCESS_KEY }}
            # ... คำสั่ง Deploy อื่นๆ
  

ข้อควรระวัง: Secrets จะไม่ถูกแสดงใน Logs ของ Workflow เว้นแต่คุณจะตั้งใจ echo ออกมาเอง ซึ่งไม่แนะนำอย่างยิ่งครับ ควรระมัดระวังไม่ให้เผลอพิมพ์ค่า Secret ออกมาใน Log โดยไม่ตั้งใจครับ

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

ลงมือสร้าง CI Pipeline ด้วย GitHub Actions (ตัวอย่างที่ 1: Build & Test แอปพลิเคชัน Node.js)

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

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

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

ตัวอย่างเช่น คุณอาจจะมีไฟล์ชื่อ ci-nodejs.yml หรือ main.yml ครับ

your-repo/
├── .github/
│   └── workflows/
│       └── ci-nodejs.yml # ไฟล์ Workflow ของเรา
├── src/
│   └── index.js
├── test/
│   └── index.test.js
├── package.json
└── README.md

ตัวอย่าง CI Workflow สำหรับ Node.js

สมมติว่าคุณมีโปรเจกต์ Node.js ที่มีไฟล์ package.json และมี script สำหรับ test เช่น npm test ครับ นี่คือตัวอย่าง Workflow ที่จะทำการบิวด์และทดสอบโปรเจกต์ของคุณ

# .github/workflows/ci-nodejs.yml

name: Node.js CI Pipeline

# กำหนด Event ที่จะกระตุ้น Workflow นี้
on:
  push:
    branches: [ "main", "develop" ] # รันเมื่อมีการ push โค้ดไปยัง branch 'main' หรือ 'develop'
  pull_request:
    branches: [ "main", "develop" ] # รันเมื่อมีการสร้าง Pull Request ไปยัง branch 'main' หรือ 'develop'

# กำหนด Job ที่จะรันใน Workflow
jobs:
  build-and-test:
    # กำหนด Runner ที่จะใช้
    runs-on: ubuntu-latest # ใช้ Ubuntu Linux เวอร์ชันล่าสุด

    # Steps ที่จะรันใน Job นี้
    steps:
      # Step 1: Checkout โค้ดจาก Repository
      - name: Checkout repository
        uses: actions/checkout@v4 # ใช้ Action 'checkout' เพื่อดึงโค้ด

      # Step 2: ตั้งค่า Node.js Environment
      - name: Set up Node.js
        uses: actions/setup-node@v4 # ใช้ Action 'setup-node'
        with:
          node-version: '20' # กำหนดเวอร์ชัน Node.js ที่จะใช้

      # Step 3: ติดตั้ง Dependencies
      - name: Install dependencies
        run: npm install # รันคำสั่ง npm install

      # Step 4: รัน Unit Tests
      - name: Run tests
        run: npm test # รันคำสั่ง npm test

      # Step 5 (Optional): สร้าง Build Artifacts (เช่น JavaScript bundles)
      # หากโปรเจกต์ของคุณเป็น Frontend ที่ต้อง Build
      # - name: Build project
      #   run: npm run build

      # Step 6 (Optional): อัปโหลด Artifacts
      # หากคุณต้องการเก็บไฟล์ที่บิวด์ได้
      # - name: Upload artifacts
      #   uses: actions/upload-artifact@v4
      #   with:
      #     name: node-app-build
      #     path: dist/ # เปลี่ยน path เป็น directory ที่เก็บไฟล์ build ของคุณ

อธิบายแต่ละส่วนของ CI Workflow โดยละเอียด

มาดูกันว่าแต่ละบรรทัดในไฟล์ YAML ด้านบนมีความหมายอย่างไรบ้างครับ

• name: Node.js CI Pipeline

  ชื่อของ Workflow นี้ครับ จะปรากฏในหน้า GitHub Actions ของ repository คุณ ทำให้ง่ายต่อการระบุ Workflow ที่กำลังทำงานอยู่

• on:

  ส่วนนี้ใช้กำหนด Event ที่จะกระตุ้นให้ Workflow นี้เริ่มทำงานครับ

  • push:

    หมายถึง Workflow จะทำงานเมื่อมีการ push โค้ดไปยัง repository

    • branches: [ "main", "develop" ]

      ระบุว่าให้รัน Workflow เฉพาะเมื่อมีการ push ไปยัง branch main หรือ develop เท่านั้น

  • pull_request:

    หมายถึง Workflow จะทำงานเมื่อมีการสร้างหรืออัปเดต pull_request ที่มีเป้าหมายไปยัง branch ที่ระบุ

    • branches: [ "main", "develop" ]

      เช่นเดียวกัน ให้รัน Workflow เฉพาะเมื่อ Pull Request นั้นมีเป้าหมายไปยัง branch main หรือ develop

  คุณสามารถกำหนด Events ได้หลากหลาย เช่น schedule (รันตามเวลาที่กำหนด), workflow_dispatch (รันด้วยมือ), release และอื่นๆ อีกมากมายครับ

• jobs:

  ส่วนนี้คือที่ที่คุณกำหนด Jobs ที่จะรันใน Workflow ครับ ในตัวอย่างนี้ เรามี Job เดียวชื่อ build-and-test

  • build-and-test:

    ชื่อของ Job นี้

    • runs-on: ubuntu-latest

      ระบุ Runner ที่จะใช้ในการรัน Job นี้ครับ ubuntu-latest คือ GitHub-hosted runner ที่เป็นระบบปฏิบัติการ Ubuntu เวอร์ชันล่าสุด นอกจากนี้ยังมี windows-latest และ macos-latest ให้เลือกใช้ครับ

    • steps:

      รายการของ Steps ที่จะรันตามลำดับภายใน Job นี้ครับ

      • - name: Checkout repository

        ชื่อของ Step นี้ เพื่อความชัดเจนใน Log

        • uses: actions/checkout@v4

          ใช้ Action ชื่อ actions/checkout@v4 ครับ Action นี้มีหน้าที่ดึง (checkout) โค้ดจาก repository ของคุณไปยัง Runner เพื่อให้ Steps ถัดไปสามารถเข้าถึงโค้ดได้

      • - name: Set up Node.js

        ตั้งค่าสภาพแวดล้อม Node.js

        • uses: actions/setup-node@v4

          ใช้ Action actions/setup-node@v4 เพื่อติดตั้ง Node.js บน Runner

        • with:

          ใช้สำหรับส่งผ่านพารามิเตอร์ไปยัง Action

          • node-version: '20'

            ระบุเวอร์ชันของ Node.js ที่ต้องการติดตั้ง ในที่นี้คือเวอร์ชัน 20

      • - name: Install dependencies

        ติดตั้งแพ็กเกจ Node.js ที่ระบุใน package.json

        • run: npm install

          ใช้ run: เพื่อรันคำสั่ง Shell script ครับ ในที่นี้คือ npm install

      • - name: Run tests

        รัน Unit Tests ของโปรเจกต์

        • run: npm test

          รันคำสั่ง npm test ซึ่งโดยทั่วไปจะถูกกำหนดไว้ใน package.json เพื่อเรียกใช้ Test Runner เช่น Jest, Mocha ครับ

หลังจากที่คุณ commit ไฟล์ ci-nodejs.yml นี้ไปยัง repository ของคุณ และ push ไปยัง branch main หรือ develop (หรือสร้าง Pull Request) GitHub Actions จะตรวจจับ Event และเริ่มรัน Workflow นี้โดยอัตโนมัติครับ คุณสามารถดูสถานะและ Log ของการรัน Workflow ได้ในแท็บ “Actions” ของ repository บน GitHub ครับ

นี่คือพื้นฐานของ CI Pipeline ด้วย GitHub Actions ครับ ด้วย Workflow ง่ายๆ นี้ คุณก็ได้สร้างกระบวนการอัตโนมัติในการบิวด์และทดสอบโค้ดของคุณแล้วครับ!

ขยายสู่ CD Pipeline: การ Deploy แอปพลิเคชันโดยอัตโนมัติ (ตัวอย่างที่ 2: Deploy Static Site ไปยัง GitHub Pages)

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

แนวคิดการ Deploy: Staging และ Production

ในโลกแห่งความเป็นจริง การ Deploy แอปพลิเคชันมักจะทำผ่านหลายสภาพแวดล้อม (environments) ครับ

• Staging Environment:

  เป็นสภาพแวดล้อมที่จำลอง Production Environment มามากที่สุด ใช้สำหรับการทดสอบขั้นสุดท้าย (User Acceptance Testing – UAT), การทดสอบประสิทธิภาพ, และการตรวจสอบโดยผู้มีส่วนได้ส่วนเสียก่อนที่จะ Deploy ไปยัง Production จริงครับ

• Production Environment:

  คือสภาพแวดล้อมที่ผู้ใช้งานจริงเข้าถึงครับ การ Deploy ไปยัง Production มักจะต้องผ่านการอนุมัติหรือเงื่อนไขบางอย่าง เพื่อลดความเสี่ยงที่อาจเกิดขึ้นกับผู้ใช้งาน

ในตัวอย่างของเรา การ Deploy ไปยัง GitHub Pages อาจถูกมองว่าเป็น Production Environment โดยตรงสำหรับ Static Site ครับ แต่หลักการ Deploy ไปยัง Cloud Providers อื่นๆ ก็จะมีขั้นตอนคล้ายกัน โดยอาจจะต้องใช้ Secrets สำหรับ Credentials และกำหนด Environment ใน GitHub Actions ครับ

ตัวอย่าง CD Workflow สำหรับ Static Site ไปยัง GitHub Pages

สมมติว่าคุณมี Static Site (เช่น สร้างด้วย React, Vue, หรือ Jekyll) ที่หลังจาก npm run build แล้ว จะมีไฟล์ HTML, CSS, JS อยู่ในโฟลเดอร์ dist/ ครับ เราจะสร้าง Workflow เพื่อบิวด์โปรเจกต์และ Deploy โฟลเดอร์ dist/ ไปยัง GitHub Pages ครับ

ไฟล์ Workflow นี้จะแยกเป็นอีก Job หนึ่งที่รันหลังจาก Job build-and-test สำเร็จแล้ว

# .github/workflows/cd-github-pages.yml

name: Deploy Static Site to GitHub Pages

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

# กำหนด Default permissions สำหรับ Workflow นี้
# เพื่อความปลอดภัย ควรให้สิทธิ์เท่าที่จำเป็นเท่านั้น
permissions:
  contents: write # จำเป็นสำหรับการ push โค้ดไปยัง gh-pages branch
  pages: write # จำเป็นสำหรับการ Deploy ไปยัง GitHub Pages
  id-token: write # จำเป็นสำหรับการยืนยันตัวตนกับ GitHub Pages

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment:
      name: github-pages # กำหนด environment เป็น github-pages
      url: ${{ steps.deployment.outputs.page_url }} # URL ของ GitHub Pages ที่ถูก Deploy

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

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

      - name: Install dependencies
        run: npm install

      - name: Build project
        run: npm run build # คำสั่ง build โปรเจกต์ของคุณ (เช่น สร้างไฟล์ใน dist/)

      # Step 1: ตั้งค่า GitHub Pages
      - name: Setup Pages
        uses: actions/configure-pages@v4 # Action สำหรับตั้งค่า GitHub Pages

      # Step 2: อัปโหลด Artifact สำหรับ GitHub Pages
      # ไฟล์ที่อยู่ใน 'dist/' จะถูกอัปโหลดเป็น artifact
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: './dist' # โฟลเดอร์ที่เก็บไฟล์ build ของคุณ

      # Step 3: Deploy ไปยัง GitHub Pages
      - name: Deploy to GitHub Pages
        id: deployment # กำหนด id ให้กับ step นี้เพื่ออ้างอิง output
        uses: actions/deploy-pages@v4 # Action สำหรับ Deploy GitHub Pages

อธิบายแต่ละส่วนของ CD Workflow โดยละเอียด

เรามาดูส่วนที่แตกต่างจาก CI Workflow และส่วนสำคัญของ CD Workflow กันครับ

• on: push: branches: [ "main" ]

  ใน CD Pipeline เรามักจะกำหนดให้ Workflow ทำงานเมื่อมีการ push ไปยัง Branch ที่เป็น Production (เช่น main) เท่านั้น เพื่อให้มั่นใจว่าโค้ดที่ถูก Deploy คือโค้ดที่ผ่านการทดสอบและอนุมัติแล้วครับ

• permissions:

  ส่วนนี้เป็นสิ่งใหม่และสำคัญสำหรับ Security Context ครับ โดยปกติ GitHub Actions จะรันด้วย token ที่มีสิทธิ์จำกัด การ Deploy ไปยัง GitHub Pages ต้องการสิทธิ์เฉพาะ:

  • contents: write: สำหรับการสร้างหรืออัปเดตไฟล์ใน repository (บาง Action อาจจะสร้าง branch gh-pages หรือ commit ไฟล์)
  • pages: write: สิทธิ์เฉพาะสำหรับการ Deploy ไปยัง GitHub Pages
  • id-token: write: สำหรับการยืนยันตัวตน (authentication) กับ GitHub Pages (ซึ่งใช้ OpenID Connect)

  การกำหนดสิทธิ์อย่างเหมาะสมเป็น Best Practice ด้านความปลอดภัยครับ

• environment:

  คุณสามารถกำหนด Environment ให้กับ Job ได้ ซึ่งช่วยในการจัดการ Secrets, การตรวจสอบการ Deploy (Deployment Protections), และการแสดงผลในหน้า GitHub Actions ครับ

  • name: github-pages: ชื่อ Environment ที่เราสร้างขึ้นมา
  • url: ${{ steps.deployment.outputs.page_url }}: ดึง URL ของ GitHub Pages ที่ถูก Deploy สำเร็จ เพื่อแสดงในหน้า Workflow Run ครับ
• - name: Build project

  Step นี้คือการรันคำสั่งบิวด์โปรเจกต์ของคุณ เช่น npm run build ซึ่งจะสร้างไฟล์ที่พร้อมสำหรับการ Deploy ไว้ในโฟลเดอร์ เช่น dist/ หรือ build/ ครับ

• - name: Setup Pages
  • uses: actions/configure-pages@v4: Action นี้มีหน้าที่ตั้งค่าสภาพแวดล้อมที่จำเป็นสำหรับการ Deploy ไปยัง GitHub Pages ครับ
• - name: Upload artifact
  • uses: actions/upload-pages-artifact@v3: Action นี้จะอัปโหลดโฟลเดอร์ dist/ (หรือโฟลเดอร์ที่คุณระบุ) เป็น Artifact ที่ GitHub Pages สามารถนำไปใช้ในการ Deploy ได้ครับ
  • with: path: './dist': ระบุพาธของโฟลเดอร์ที่ต้องการอัปโหลด
• - name: Deploy to GitHub Pages
  • id: deployment: กำหนด ID ให้กับ Step นี้ เพื่อให้เราสามารถอ้างอิงถึง Output ของ Step นี้ได้ (เช่น steps.deployment.outputs.page_url)
  • uses: actions/deploy-pages@v4: Action สุดท้ายนี้จะนำ Artifact ที่เราอัปโหลดไว้ก่อนหน้า ไป Deploy ขึ้น GitHub Pages ครับ

หลังจากที่คุณ Commit และ Push ไฟล์ cd-github-pages.yml ไปยัง Branch main Workflow นี้จะทำงานโดยอัตโนมัติ และเมื่อสำเร็จ เว็บไซต์ของคุณก็จะถูก Deploy ไปยัง GitHub Pages พร้อมให้เข้าถึงได้แล้วครับ!

นี่เป็นตัวอย่างพื้นฐานของ CD Pipeline ครับ สำหรับการ Deploy ไปยัง Cloud Providers อื่นๆ เช่น AWS, Azure, GCP ก็จะมี Actions เฉพาะสำหรับบริการเหล่านั้น และมักจะใช้ Secrets สำหรับการยืนยันตัวตนครับ แต่หลักการโดยรวมก็ยังคงเหมือนเดิมคือ: Build > Package > Deploy ครับ

Advanced GitHub Actions Techniques & Best Practices

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

Matrix Builds

บางครั้งคุณอาจต้องการรัน Job เดียวกันบนหลายสภาพแวดล้อม (เช่น ทดสอบแอปพลิเคชันของคุณบน Node.js หลายเวอร์ชัน, หรือบนระบบปฏิบัติการที่แตกต่างกัน) Matrix Builds ช่วยให้คุณสามารถทำสิ่งนี้ได้อย่างมีประสิทธิภาพครับ

jobs:
  test:
    runs-on: ${{ matrix.os }} # Runner จะมาจาก matrix.os
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest] # รันบน Ubuntu และ Windows
        node-version: [18, 20, 22] # ทดสอบกับ Node.js 3 เวอร์ชัน
    name: Test on Node ${{ matrix.node-version }} on ${{ matrix.os }} # ชื่อ Job สำหรับแต่ละ Matrix Combination

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

จากตัวอย่างนี้ Workflow จะสร้าง Job ย่อยขึ้นมาทั้งหมด 2 (OS) x 3 (Node versions) = 6 Jobs เพื่อทดสอบแอปพลิเคชันของคุณบนทุก Combinations ที่ระบุครับ

การทำ Caching Dependencies

การติดตั้ง Dependencies เช่น npm install, pip install, หรือ composer install อาจใช้เวลานานในแต่ละ Workflow Run ครับ การใช้ Caching สามารถช่วยเร่งความเร็วของ Workflow ได้อย่างมาก โดยการเก็บ Dependencies ที่ดาวน์โหลดไว้แล้วไว้บน Runner และนำกลับมาใช้ใหม่ในการรันครั้งถัดไป

steps:
  - uses: actions/checkout@v4
  - name: Set up Node.js
    uses: actions/setup-node@v4
    with:
      node-version: '20'
  - name: Cache Node.js modules
    uses: actions/cache@v4 # ใช้ Action สำหรับ Caching
    with:
      path: ~/.npm # พาธที่จะ Cache (สำหรับ npm)
      key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} # Key สำหรับ Cache
      restore-keys: |
        ${{ runner.os }}-node-
  - name: Install dependencies
    run: npm install

key จะใช้ hashFiles('**/package-lock.json') เพื่อสร้าง Key ที่ไม่ซ้ำกัน หากไฟล์ package-lock.json เปลี่ยนไป Cache ก็จะถูกสร้างใหม่ครับ restore-keys ช่วยในการดึง Cache ที่ใกล้เคียงที่สุดหาก Key หลักไม่ตรง

Reusable Workflows และ Composite Actions

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

• Reusable Workflows:

  เป็น Workflow เต็มรูปแบบที่สามารถเรียกใช้จาก Workflow อื่นได้ เหมาะสำหรับ Logic ที่ซับซ้อนและมีหลาย Jobs เช่น การ Deploy มาตรฐานไปยัง Production

  # .github/workflows/reusable-deploy.yml (Workflow ที่ถูกเรียกใช้)
  name: Reusable Deploy Workflow
  on:
    workflow_call: # ถูกเรียกใช้โดย Workflow อื่น
      inputs:
        environment:
          required: true
          type: string
      secrets:
        deploy_token:
          required: true
      # ... logic การ deploy ...
  
  # .github/workflows/main-app.yml (Workflow ที่เรียกใช้)
  jobs:
    call-deploy:
      uses: octo-org/octo-repo/.github/workflows/reusable-deploy.yml@main # เรียกใช้ Reusable Workflow
      with:
        environment: production
      secrets:
        deploy_token: ${{ secrets.PROD_DEPLOY_TOKEN }}
  

• Composite Actions:

  เป็น Action ที่ประกอบด้วยหลาย Steps รวมกันเป็น Action เดียว เหมาะสำหรับชุดคำสั่งที่ใช้บ่อยในหลายๆ Workflow หรือหลายๆ Job เช่น การตั้งค่า environment หรือการรันชุดคำสั่งเฉพาะ

  # .github/actions/setup-and-install/action.yml (Composite Action)
  name: 'Setup Node.js and Install Dependencies'
  description: 'Sets up Node.js and runs npm install'
  inputs:
    node-version:
      description: 'Version of Node.js to use'
      required: true
      default: '20'
  runs:
    using: "composite"
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm install
        shell: bash
  
  # .github/workflows/my-workflow.yml (เรียกใช้ Composite Action)
  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - uses: ./.github/actions/setup-and-install # เรียกใช้ Composite Action
          with:
            node-version: '20'
        - run: npm test
  

Environment Protection Rules และ Approvals

สำหรับการ Deploy ไปยัง Production Environment การมีระบบป้องกันและความปลอดภัยเป็นสิ่งสำคัญ GitHub Actions อนุญาตให้คุณกำหนด Protection Rules สำหรับ Environments ได้ ซึ่งรวมถึงการต้องมีการอนุมัติด้วยมือ (Manual Approval) ก่อนการ Deploy

1. ไปที่ Repository Settings > Environments
2. สร้าง Environment ใหม่ (เช่น Production)
3. กำหนด Protection Rules เช่น “Required reviewers” (ต้องมีคนอนุมัติก่อน) หรือ “Wait timer” (รอตามเวลาที่กำหนด)

jobs:
  deploy-to-production:
    runs-on: ubuntu-latest
    environment: # อ้างถึง Environment ที่เราสร้างไว้
      name: Production
      url: https://your-app.com # URL ของแอปพลิเคชันที่ Deploy
    steps:
      # ... steps สำหรับ Deploy

เมื่อมีการรัน Workflow ที่มี Job ที่กำหนด environment: Production GitHub จะหยุด Workflow ชั่วคราวและรอการอนุมัติจากผู้ตรวจสอบที่คุณกำหนดไว้ครับ

Self-hosted Runners

GitHub-hosted runners นั้นสะดวกและครอบคลุมการใช้งานทั่วไป แต่สำหรับบางกรณี เช่น

• คุณต้องการฮาร์ดแวร์ที่เฉพาะเจาะจง (เช่น GPU)
• ต้องการเข้าถึงทรัพยากรภายในเครือข่ายส่วนตัวของคุณ
• ต้องการควบคุมสภาพแวดล้อมของ Runner อย่างสมบูรณ์

คุณสามารถตั้งค่า Self-hosted Runners บนเซิร์ฟเวอร์ของคุณเองได้ครับ Runner เหล่านี้จะเชื่อมต่อกับ GitHub และรอรับงานจาก Workflow ของคุณ การตั้งค่าจะซับซ้อนกว่า GitHub-hosted runners เล็กน้อย แต่ให้ความยืดหยุ่นและการควบคุมที่เหนือกว่าครับ

jobs:
  my-custom-job:
    runs-on: self-hosted # ระบุว่าให้รันบน Self-hosted Runner
    steps:
      # ...

การใช้งาน GitHub Packages และ Artifacts

• Artifacts:

  คุณสามารถอัปโหลดไฟล์ที่ถูกสร้างขึ้นระหว่าง Workflow (เช่น Build artifacts, Test reports) เป็น Artifacts เพื่อให้สามารถดาวน์โหลดได้ในภายหลัง หรือใช้โดย Job อื่นๆ ใน Workflow เดียวกันครับ

  # อัปโหลด Artifact
  - name: Upload Build Artifact
    uses: actions/upload-artifact@v4
    with:
      name: my-app-build
      path: dist/ # โฟลเดอร์ที่เก็บไฟล์ build
  
  # ดาวน์โหลด Artifact ใน Job อื่น
  - name: Download Build Artifact
    uses: actions/download-artifact@v4
    with:
      name: my-app-build
      path: ./downloaded-build
  

• GitHub Packages:

  GitHub Packages เป็นบริการสำหรับโฮสต์แพ็กเกจซอฟต์แวร์ (เช่น npm, Maven, Docker images) ได้โดยตรงใน GitHub ครับ คุณสามารถใช้ GitHub Actions เพื่อบิวด์และพุช Docker Image ไปยัง GitHub Packages Registry ได้โดยตรง และดึงกลับมาใช้ในการ Deploy ได้ครับ

  # พุช Docker Image ไปยัง GitHub Packages
  - name: Build & Push Docker Image
    uses: docker/build-push-action@v5
    with:
      context: .
      push: true
      tags: ghcr.io/${{ github.repository }}/my-app:latest
      username: ${{ github.actor }}
      password: ${{ secrets.GITHUB_TOKEN }} # ใช้ GITHUB_TOKEN สำหรับ auth
  

การมอนิเตอร์และแก้ไขปัญหา Workflow

• ตรวจสอบ Log: ทุกครั้งที่ Workflow รัน คุณสามารถเข้าไปดู Log รายละเอียดของแต่ละ Step ได้ในแท็บ “Actions” ของ repository ครับ Log เหล่านี้เป็นแหล่งข้อมูลสำคัญในการแก้ไขปัญหา
• Use echo และ env: ใช้คำสั่ง echo เพื่อแสดงค่าตัวแปร หรือใช้ env ใน Step เพื่อแสดง Environment Variables ที่ใช้
• Debug ด้วย SSH: สำหรับ Self-hosted runners คุณสามารถ SSH เข้าไปที่ Runner เพื่อตรวจสอบปัญหาได้โดยตรง
• Workflow Run Status: GitHub จะแสดงสถานะของ Workflow Run อย่างชัดเจน (Success, Failure, Cancelled)

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

• Least Privilege: ให้สิทธิ์ (Permissions) แก่ Workflow และ Secrets เท่าที่จำเป็นเท่านั้นครับ
• Secrets Management: ใช้ GitHub Secrets เสมอสำหรับข้อมูลที่ละเอียดอ่อน ห้าม hardcode ไว้ในไฟล์ Workflow
• Code Review: ตรวจสอบไฟล์ Workflow (YAML) เช่นเดียวกับโค้ดแอปพลิเคชันปกติ
• Pin Actions to Full Length Commit SHAs: แทนที่จะใช้ uses: actions/checkout@v4 ควรใช้ uses: actions/checkout@COMMIT_SHA เพื่อป้องกันการเปลี่ยนแปลงที่ไม่คาดคิดใน Action เวอร์ชันใหม่ครับ (แม้ว่า @v4 จะเป็นเวอร์ชันที่เสถียรแล้ว แต่ SHA ที่แม่นยำกว่าจะให้ความมั่นใจสูงสุด)
• OpenID Connect (OIDC): ใช้ OIDC สำหรับการยืนยันตัวตนกับ Cloud Providers แทนการใช้ Long-lived API Keys เพื่อลดความเสี่ยงด้านความปลอดภัยครับ

การนำเทคนิคและ Best Practices เหล่านี้ไปใช้จะช่วยให้ CI/CD Pipeline ของคุณด้วย GitHub Actions มีความแข็งแกร่ง ปลอดภัย และจัดการได้ดียิ่งขึ้นครับ

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

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

สรุปการเลือก:

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

การเลือกเครื่องมือ CI/CD ควรพิจารณาจากข้อกำหนดของโปรเจกต์, ขนาดของทีม, งบประมาณ, และความคุ้นเคยกับแพลตฟอร์มต่างๆ ครับ

กรณีศึกษา (Use Case Scenarios)

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

Web Application (Frontend/Backend)

• Frontend (React, Vue, Angular):

  CI: รัน npm install, npm test (Jest, Vitest), eslint, prettier, บิวด์โปรเจกต์ด้วย npm run build

  CD: อัปโหลด Artifact ที่บิวด์ได้ไปยัง S3 (AWS), Azure Blob Storage, หรือ Deploy ไปยัง Netlify/Vercel/GitHub Pages

• Backend (Node.js, Python/Django/Flask, Java/Spring Boot, Go):

  CI: ติดตั้ง Dependencies, รัน Unit/Integration Tests, สร้าง Docker Image

  CD: พุช Docker Image ไปยัง Docker Hub/ECR/ACR/GCR, Deploy Image ไปยัง Kubernetes Cluster, AWS ECS/EKS, Azure App Service, Google Cloud Run ผ่าน SSH หรือ Cloud SDK Actions

Mobile App CI/CD

• iOS (Swift/Objective-C):

  CI: ใช้ macOS Runner, ติดตั้ง Cocoapods/Carthage, รัน Unit/UI Tests ด้วย Xcodebuild

  CD: บิวด์ IPA, อัปโหลดไปยัง TestFlight หรือ App Store Connect (โดยใช้ Fastlane Actions)

• Android (Kotlin/Java):

  CI: ใช้ Ubuntu/macOS Runner, ติดตั้ง Gradle, รัน Unit/Instrumentation Tests

  CD: บิวด์ APK/AAB, อัปโหลดไปยัง Google Play Store (โดยใช้ Fastlane Actions หรือ Google Play Publisher Action)

• React Native/Flutter:

  สามารถใช้ Workflow เดียวกันสำหรับทั้ง iOS และ Android โดยใช้ Matrix Builds หรือแยก Job

  CI: ติดตั้ง Dependencies, รัน Tests

  CD: บิวด์แพลตฟอร์มเฉพาะ (iOS/Android) และ Deploy ตามขั้นตอนข้างต้น

Infrastructure as Code (IaC) Deployment

• Terraform/CloudFormation:

  CI: รัน terraform fmt, terraform validate, terraform plan เพื่อตรวจสอบความถูกต้องของ Infrastructure Code

  CD: เมื่อผ่านการอนุมัติ (Manual Approval), รัน terraform apply เพื่อ Deploy Infrastructure ไปยัง Cloud Provider ครับ

• Kubernetes Manifests/Helm Charts:

  CI: Lint Helm Charts, ตรวจสอบ Kubernetes Manifests ด้วย kubeval

  CD: Deploy Helm Chart หรือ kubectl apply ไปยัง Kubernetes Cluster

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

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

Q1: GitHub Actions มีค่าใช้จ่ายอย่างไรครับ?

A1: GitHub Actions มีบริการฟรีสำหรับ Public Repositories อย่างไม่จำกัดครับ สำหรับ Private Repositories จะมีโควต้าการใช้งานฟรีต่อเดือน (จำนวนนาทีในการรัน Workflow และพื้นที่เก็บ Artifacts) หลังจากใช้โควต้าฟรีหมดแล้ว คุณจะต้องจ่ายตามการใช้งานจริงครับ โดยราคาจะแตกต่างกันไปตามประเภทของ Runner (Ubuntu, Windows, macOS) และพื้นที่เก็บข้อมูลที่ใช้ครับ คุณสามารถตรวจสอบรายละเอียดราคาล่าสุดได้ที่ หน้า Pricing ของ GitHub Actions ครับ

Q2: ผมสามารถใช้ GitHub Actions กับ Private Repository ได้ไหมครับ?

A2: ได้ครับ คุณสามารถใช้ GitHub Actions กับ Private Repository ได้ตามปกติ เพียงแต่จะมีโควต้าการใช้งานฟรีจำกัดตามที่กล่าวไว้ในคำตอบ Q1 ครับ

Q3: GitHub Actions รองรับภาษาโปรแกรมและแพลตฟอร์มอะไรบ้างครับ?

A3: GitHub Actions รองรับภาษาโปรแกรมและแพลตฟอร์มยอดนิยมเกือบทั้งหมดครับ เนื่องจาก Runners สามารถเป็น Linux (Ubuntu), Windows, หรือ macOS ได้ คุณจึงสามารถติดตั้งและรัน Environment สำหรับภาษาต่างๆ เช่น Node.js, Python, Java, Go, .NET, Ruby, PHP, Swift, Kotlin และอื่นๆ อีกมากมายครับ นอกจากนี้ยังมี Actions สำเร็จรูปสำหรับภาษาและเฟรม