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

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

March 16, 2026
0 Views

ในโลกของการพัฒนาซอฟต์แวร์ที่เปลี่ยนแปลงอย่างรวดเร็วในปัจจุบัน การส่งมอบฟีเจอร์ใหม่ๆ และการอัปเดตอย่างต่อเนื่อง คือกุญแจสำคัญสู่ความสำเร็จ การทำด้วยมือในทุกขั้นตอนตั้งแต่การ Build, Test ไปจนถึง Deploy ไม่เพียงแต่กินเวลามากเท่านั้น แต่ยังเสี่ยงต่อข้อผิดพลาดที่เกิดจากมนุษย์ (Human Error) อีกด้วย นี่คือจุดที่แนวคิดของ CI/CD Pipeline เข้ามามีบทบาทสำคัญในการปฏิวัติกระบวนการพัฒนาซอฟต์แวร์ให้เป็นไปโดยอัตโนมัติ มีประสิทธิภาพ และน่าเชื่อถือมากยิ่งขึ้นครับ

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

สารบัญ

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

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

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

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

วัตถุประสงค์หลักของ CI คือ:

  • ตรวจจับข้อผิดพลาดได้เร็ว: การรวมโค้ดบ่อยๆ และการทดสอบอัตโนมัติ ช่วยให้พบข้อผิดพลาดได้ตั้งแต่เนิ่นๆ ทำให้แก้ไขได้ง่ายและรวดเร็วกว่าการปล่อยทิ้งไว้นานๆ ครับ
  • ลดปัญหา “Integration Hell”: เมื่อนักพัฒนาหลายคนทำงานบนส่วนต่างๆ ของโปรเจกต์ การรวมโค้ดเข้าด้วยกันในครั้งเดียวเมื่อโปรเจกต์ใกล้เสร็จอาจนำไปสู่ปัญหาความขัดแย้งที่แก้ไขได้ยาก CI ช่วยลดปัญหานี้โดยการรวมและตรวจสอบอย่างต่อเนื่องครับ
  • เพิ่มคุณภาพโค้ด: การรันการทดสอบอัตโนมัติอย่างสม่ำเสมอช่วยให้มั่นใจได้ว่าโค้ดที่ถูกรวมเข้ามานั้นทำงานได้ถูกต้องตามที่คาดหวังครับ
  • สร้าง Artifacts ที่พร้อมใช้งาน: หลังจากการ Build และทดสอบสำเร็จ CI จะสร้าง Artifacts (เช่น ไฟล์ .jar, Docker Image, หรือแพ็กเกจ) ที่พร้อมสำหรับการนำไปใช้งานในขั้นตอนต่อไปครับ

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

Continuous Delivery (CD) เป็นส่วนต่อขยายจาก CI โดยมุ่งเน้นไปที่การทำให้กระบวนการ Deploy ซอฟต์แวร์เป็นไปโดยอัตโนมัติ หลังจากที่โค้ดผ่านขั้นตอน CI (Build และ Test) เรียบร้อยแล้ว ระบบ CD จะเตรียมซอฟต์แวร์ให้พร้อมสำหรับการ Deploy ไปยังสภาพแวดล้อมต่างๆ เช่น Staging, UAT (User Acceptance Testing) หรือ Production ครับ

หัวใจสำคัญของ Continuous Delivery คือ:

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

กล่าวคือ Continuous Delivery ทำให้คุณมั่นใจได้ว่าคุณสามารถ Deploy ซอฟต์แวร์เวอร์ชันล่าสุดที่ใช้งานได้จริงไปยังสภาพแวดล้อม Production ได้ทุกเมื่อที่คุณต้องการ เพียงแค่กดปุ่ม หรือได้รับการอนุมัติเท่านั้นครับ

1.3. Continuous Deployment (CD) คืออะไร?

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

คุณสมบัติหลักของ Continuous Deployment คือ:

  • Deploy อัตโนมัติเต็มรูปแบบ: ทุกการเปลี่ยนแปลงโค้ดที่ถูกรวมเข้ากับ Main Branch และผ่านการทดสอบ CI/CD จะถูก Deploy ไปยัง Production โดยไม่มีการอนุมัติด้วยมือครับ
  • ต้องมีการทดสอบที่ครอบคลุม: เพื่อให้ Continuous Deployment ปลอดภัย จำเป็นต้องมีชุดการทดสอบอัตโนมัติที่ครอบคลุมและน่าเชื่อถืออย่างมาก รวมถึงการทดสอบ End-to-End, Performance Tests, และ Security Scans ครับ
  • ลด Lead Time: ช่วยลดระยะเวลาตั้งแต่การเขียนโค้ดจนถึงการนำไปใช้งานจริง (Lead Time) ได้อย่างมาก ทำให้องค์กรสามารถส่งมอบฟีเจอร์ใหม่ๆ และแก้ไขข้อผิดพลาดได้อย่างรวดเร็วครับ

Continuous Deployment เหมาะสำหรับองค์กรที่มีวัฒนธรรม DevOps ที่แข็งแกร่ง และมีระบบตรวจสอบและแก้ไขปัญหา (Monitoring and Alerting) ที่ยอดเยี่ยม เพื่อให้มั่นใจว่าการ Deploy อัตโนมัติจะไม่ก่อให้เกิดปัญหาที่ไม่คาดคิดครับ

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

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

  • ลดความเสี่ยงและตรวจจับข้อผิดพลาดได้เร็วขึ้น:

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

  • เพิ่มความเร็วในการส่งมอบ (Speed of Delivery):

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

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

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

  • ลดต้นทุนในการพัฒนา:

    แม้ว่าการลงทุนเริ่มต้นในการตั้งค่า CI/CD อาจมีอยู่บ้าง แต่ในระยะยาวแล้ว CI/CD ช่วยลดต้นทุนได้อย่างมาก โดยลดเวลาที่ใช้ในการ Debug, ลด Human Error, และเพิ่มประสิทธิภาพในการทำงานของนักพัฒนา ทำให้พวกเขามีเวลาโฟกัสกับการสร้างสรรค์ฟีเจอร์ใหม่ๆ มากกว่าการแก้ไขปัญหาเดิมๆ ครับ

  • เพิ่มความพึงพอใจของนักพัฒนา:

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

  • เพิ่มความน่าเชื่อถือและความมั่นคงของระบบ:

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

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

2. แนะนำ GitHub Actions: หัวใจสำคัญของ CI/CD บน GitHub

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

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

GitHub Actions คือแพลตฟอร์มอัตโนมัติในตัวของ GitHub ที่ช่วยให้คุณสามารถสร้าง Workflow ที่กำหนดเองได้ เพื่อตอบสนองต่อเหตุการณ์ (Events) ต่างๆ ใน Repository ของคุณ เช่น การ Push โค้ด, การเปิด Pull Request, การสร้าง Release หรือแม้แต่การตั้งเวลา (Schedule) ครับ

พูดง่ายๆ ก็คือ GitHub Actions ช่วยให้คุณสามารถทำสิ่งต่างๆ ได้โดยอัตโนมัติใน Repository ของคุณ ไม่ว่าจะเป็นการ Build โค้ด, การรันการทดสอบ, การวิเคราะห์โค้ด, การจัดการแพ็กเกจ, การ Deploy แอปพลิเคชัน ไปจนถึงการส่งการแจ้งเตือนต่างๆ ซึ่งทั้งหมดนี้จะถูกกำหนดอยู่ในไฟล์ YAML ที่เก็บไว้ใน Repository เดียวกันกับโค้ดของคุณครับ

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

2.2. สถาปัตยกรรมของ GitHub Actions: Workflows, Events, Jobs, Steps, Actions, Runners

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

  • Workflow:

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

    ตัวอย่างไฟล์ Workflow (main.yml):

    name: CI/CD Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
  • Events:

    Event คือกิจกรรมที่เกิดขึ้นใน Repository ของคุณ ซึ่งเป็นตัวทริกเกอร์ให้ Workflow ทำงานครับ ตัวอย่าง Event ทั่วไปได้แก่:

    • push: เมื่อมีการ Push โค้ดไปยัง Repository
    • pull_request: เมื่อมีการเปิด, อัปเดต, หรือปิด Pull Request
    • workflow_dispatch: อนุญาตให้รัน Workflow ได้ด้วยตนเอง (Manual Trigger)
    • schedule: รัน Workflow ตามเวลาที่กำหนด (เช่น ทุกวันตอนเที่ยงคืน)
    • release: เมื่อมีการสร้าง, อัปเดต, หรือลบ Release

    คุณสามารถระบุ Event ที่ต้องการในส่วน on: ของไฟล์ Workflow ครับ

  • Jobs:

    Job คือชุดของ Steps ที่รันอยู่บน Runner เดียวกันครับ แต่ละ Job จะรันในสภาพแวดล้อมที่แยกจากกัน (Isolated Environment) และสามารถรันแบบขนานกัน (Parallel) หรือรันตามลำดับ (Sequential) ก็ได้ครับ หาก Job หนึ่งขึ้นอยู่กับ Job อื่น (needs:) Job นั้นจะรอให้ Job ที่ขึ้นอยู่สำเร็จก่อนจึงจะเริ่มทำงาน

    ในตัวอย่างด้านบน build-and-test คือหนึ่ง Job ครับ

  • Steps:

    Step คือลำดับของคำสั่งแต่ละคำสั่งภายใน Job ครับ Step สามารถเป็นได้ทั้งการรันคำสั่ง Shell (run:) หรือการใช้ Action ที่มีอยู่แล้ว (uses:) ครับ แต่ละ Step จะทำสิ่งเล็กๆ อย่างใดอย่างหนึ่ง เช่น Checkout โค้ด, ติดตั้ง Node.js, ติดตั้ง Dependencies, หรือรันการทดสอบครับ

    ในตัวอย่างด้านบน - uses: actions/checkout@v4 และ - name: Setup Node.js คือ Steps ครับ

  • Actions:

    Action คือชุดของคำสั่งที่สามารถนำกลับมาใช้ใหม่ได้ (Reusable) ซึ่งถูกสร้างขึ้นโดย GitHub, ชุมชน, หรือตัวคุณเองครับ Actions ช่วยลดความซับซ้อนในการเขียน Workflow โดยที่คุณไม่ต้องเขียนโค้ดสำหรับงานทั่วไปซ้ำๆ เช่น การ Checkout โค้ด (actions/checkout), การตั้งค่าภาษาโปรแกรม (actions/setup-node), หรือการ Deploy ไปยัง Cloud Providers ต่างๆ

    คุณสามารถค้นหา Actions ได้ที่ GitHub Marketplace ครับ

  • Runners:

    Runner คือเซิร์ฟเวอร์ที่รัน Job ใน Workflow ของคุณครับ GitHub Actions มี Runner ให้เลือกใช้หลายประเภท:

    • GitHub-hosted Runners: เป็นเครื่องเสมือนที่ GitHub จัดเตรียมให้ ซึ่งมีระบบปฏิบัติการและเครื่องมือต่างๆ ติดตั้งไว้ล่วงหน้า เช่น Ubuntu, Windows, macOS คุณไม่ต้องดูแลรักษาสิ่งเหล่านี้เอง แต่มีการจำกัดการใช้งานฟรีครับ
    • Self-hosted Runners: เป็นเครื่องที่คุณตั้งค่าและดูแลเอง ไม่ว่าจะเป็นเซิร์ฟเวอร์ของคุณเองใน Data Center หรือ VM ใน Cloud ที่คุณเป็นเจ้าของ คุณสามารถใช้ Self-hosted Runners ได้เมื่อต้องการควบคุมสภาพแวดล้อมอย่างเต็มที่, ใช้ Hardware ที่มีประสิทธิภาพสูง หรือเมื่อต้องการหลีกเลี่ยงข้อจำกัดของ GitHub-hosted Runners ครับ

    คุณระบุประเภท Runner ที่ต้องการในส่วน runs-on: ของ Job ครับ

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

2.3. ข้อดีของการใช้ GitHub Actions สำหรับ CI/CD

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

  • การผนวกรวมที่ไร้รอยต่อกับ GitHub (Native Integration):

    เนื่องจาก GitHub Actions ถูกสร้างขึ้นโดย GitHub เอง จึงทำงานร่วมกับฟีเจอร์อื่นๆ ของ GitHub ได้อย่างสมบูรณ์แบบ ไม่ว่าจะเป็น Issues, Pull Requests, Releases, หรือ GitHub Packages การตั้งค่าและจัดการ Workflow ทำได้ง่ายดายจาก Repository ของคุณโดยตรงครับ

  • โครงสร้างไฟล์ YAML ที่เข้าใจง่าย:

    Workflow ถูกกำหนดด้วยไฟล์ YAML ที่อ่านและเขียนได้ง่าย ทำให้คุณสามารถกำหนดกระบวนการ CI/CD ได้อย่างชัดเจนและเป็นส่วนหนึ่งของโค้ดเบสของคุณ (Infrastructure as Code) ซึ่งช่วยให้การตรวจสอบโค้ดและการติดตามการเปลี่ยนแปลงทำได้สะดวกครับ

  • ระบบนิเวศของ Actions ที่กว้างขวาง (Marketplace):

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

  • ความยืดหยุ่นและปรับแต่งได้สูง:

    คุณสามารถสร้าง Workflow ที่ซับซ้อนได้โดยใช้ Jobs ที่รันแบบขนานหรือตามลำดับ, การใช้ Matrix Strategies สำหรับการทดสอบข้ามแพลตฟอร์ม/เวอร์ชัน, การจัดการ Environment Variables และ Secrets เพื่อความปลอดภัย, รวมถึงการใช้ Self-hosted Runners สำหรับความต้องการเฉพาะทางครับ

  • การบริหารจัดการค่าใช้จ่าย:

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

  • การสนับสนุนจากชุมชนที่แข็งแกร่ง:

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

  • ลดการ Context Switching:

    นักพัฒนาสามารถจัดการโค้ด, Pull Requests, Issues และ CI/CD Workflow ได้ในที่เดียวบน GitHub ทำให้ลดการสลับบริบทระหว่างเครื่องมือต่างๆ และเพิ่มประสิทธิภาพในการทำงานครับ

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

3. การสร้าง CI/CD Pipeline ด้วย GitHub Actions: ลงมือปฏิบัติจริง (Step-by-Step)

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

3.1. เตรียมความพร้อมก่อนเริ่ม

ก่อนที่เราจะเริ่มเขียน Workflow มีบางสิ่งที่คุณควรเตรียมไว้ก่อนครับ

  1. GitHub Repository:

    คุณต้องมี GitHub Repository ที่เก็บโค้ดโปรเจกต์ของคุณครับ ถ้ายังไม่มี สามารถสร้างใหม่ได้ง่ายๆ

  2. โปรเจกต์ตัวอย่าง:

    สำหรับบทความนี้ เราจะใช้โปรเจกต์ Node.js อย่างง่ายๆ เป็นตัวอย่าง แต่หลักการสามารถนำไปปรับใช้กับภาษาหรือ Framework อื่นๆ ได้ครับ ตัวอย่างโปรเจกต์ Node.js อาจมีไฟล์ package.json, index.js และไฟล์ทดสอบ test.js

    // index.js
const add = (a, b) => a + b;
const subtract = (a, b) => a - b;

module.exports = { add, subtract };

    // test.js
const assert = require('assert');
const { add, subtract } = require('./index');

assert.strictEqual(add(1, 2), 3, 'add(1, 2) should be 3');
assert.strictEqual(subtract(5, 2), 3, 'subtract(5, 2) should be 3');

console.log('All tests passed!');

    // package.json
{
  "name": "my-node-app",
  "version": "1.0.0",
  "description": "A simple Node.js app for CI/CD demo",
  "main": "index.js",
  "scripts": {
    "test": "node test.js",
    "start": "node index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}
  3. สิทธิ์การเข้าถึง (Permissions):

    คุณต้องมีสิทธิ์ในการ Push โค้ดไปยัง Repository และสร้างไฟล์ในไดเรกทอรี .github/workflows/ ครับ

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

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

เมื่อคุณสร้างไฟล์นี้และ Push ขึ้น GitHub Workflow จะถูกตรวจจับและพร้อมทำงานทันทีครับ

3.3. ตัวอย่างที่ 1: CI Pipeline สำหรับโปรเจกต์ Node.js (Build & Test)

เราจะเริ่มต้นด้วยการสร้าง CI Pipeline ที่จะทำการ Build และ Test โปรเจกต์ Node.js ของเราทุกครั้งที่มีการ Push โค้ดไปยัง Branch main หรือมีการเปิด/อัปเดต Pull Request ที่มีเป้าหมายเป็น Branch main ครับ

สร้างไฟล์ .github/workflows/ci.yml และเพิ่มโค้ดด้านล่างนี้:

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

# กำหนด Event ที่จะทริกเกอร์ Workflow นี้
on:
  push:
    branches:
      - main # รันเมื่อมีการ Push ไปยัง branch 'main'
  pull_request:
    branches:
      - main # รันเมื่อมี Pull Request เข้ามาที่ branch 'main'

# กำหนด Jobs ที่จะรัน
jobs:
  # Job แรก: build-and-test
  build-and-test:
    name: Build and Test Node.js App
    runs-on: ubuntu-latest # ระบุ Runner ที่จะใช้ (GitHub-hosted Ubuntu)

    steps:
      # Step 1: Checkout โค้ดจาก Repository
      # uses: actions/checkout@v4 เป็น Action ที่ใช้ดึงโค้ดโปรเจกต์ของคุณเข้ามายัง Runner
      - name: Checkout repository
        uses: actions/checkout@v4

      # Step 2: ตั้งค่า Node.js Environment
      # uses: actions/setup-node@v4 เป็น Action สำหรับติดตั้ง Node.js
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: '18' # ระบุเวอร์ชันของ Node.js ที่ต้องการใช้

      # Step 3: ติดตั้ง Dependencies ของโปรเจกต์ (จาก package.json)
      - name: Install dependencies
        run: npm install # รันคำสั่ง npm install

      # Step 4: รันการทดสอบ (Unit Tests, Integration Tests)
      - name: Run tests
        run: npm test # รันคำสั่ง npm test ที่กำหนดไว้ใน package.json

      # Step 5 (Optional): สร้าง Build Artifacts
      # ถ้าโปรเจกต์ของคุณต้องการการ Build เช่น Babel, Webpack
      # - name: Build project
      #   run: npm run build # หรือคำสั่ง build อื่นๆ ของคุณ

      # Step 6 (Optional): อัปโหลด Artifacts (เช่น Build Output)
      # หากคุณต้องการนำไฟล์ที่ Build แล้วไปใช้ใน Job ถัดไป (CD) หรือเก็บไว้
      # uses: actions/upload-artifact@v4
      # - name: Upload build artifacts
      #   uses: actions/upload-artifact@v4
      #   with:
      #     name: node-app-build
      #     path: build/ # หรือ path ที่คุณต้องการอัปโหลด

คำอธิบาย Workflow:

  • `name`: ชื่อของ Workflow ที่จะแสดงในหน้า GitHub Actions
  • `on`: กำหนดว่า Workflow จะรันเมื่อเกิด Event อะไรบ้าง ในที่นี้คือ `push` และ `pull_request` ไปยัง `main` branch
  • `jobs`: ส่วนนี้คือที่ที่คุณกำหนด Job หนึ่งหรือหลาย Job
  • `build-and-test`: ชื่อของ Job นี้
  • `runs-on: ubuntu-latest`: ระบุว่า Job นี้จะรันบน GitHub-hosted Runner ที่ใช้ Ubuntu เวอร์ชันล่าสุด
  • `steps`: ลำดับของคำสั่งที่จะรันภายใน Job นี้
  • `actions/checkout@v4`: Action ที่ใช้ Checkout โค้ดจาก Repository ของคุณ
  • `actions/setup-node@v4`: Action ที่ใช้ติดตั้ง Node.js เวอร์ชัน 18
  • `npm install`: คำสั่งสำหรับติดตั้ง Dependencies
  • `npm test`: คำสั่งสำหรับรันการทดสอบที่เรากำหนดไว้ใน `package.json`
  • `actions/upload-artifact@v4` (Optional): Action สำหรับอัปโหลด Artifacts เช่น ไฟล์ที่ Build แล้ว เพื่อให้ Job อื่นๆ สามารถดาวน์โหลดไปใช้ได้

หลังจากที่คุณบันทึกไฟล์นี้และ Push ไปยัง GitHub Repository ของคุณ GitHub Actions จะตรวจจับไฟล์ Workflow และเริ่มรัน Job `build-and-test` ทันทีเมื่อมีการ Push โค้ดหรือเปิด Pull Request ครับ คุณสามารถดูสถานะและ Log ของ Workflow ได้ที่แท็บ “Actions” ใน Repository ของคุณ

ถ้าทุกอย่างถูกต้อง คุณจะเห็น Workflow รันสำเร็จ แสดงว่า CI Pipeline ของคุณทำงานได้อย่างสมบูรณ์แล้วครับ! อ่านเพิ่มเติมเกี่ยวกับ GitHub Actions Workflows

3.4. ตัวอย่างที่ 2: CD Pipeline สำหรับ Deploy ไปยัง Server ด้วย SSH

หลังจากที่ CI Pipeline ของเราทำงานได้ดีแล้ว เราจะมาสร้าง CD Pipeline ที่จะ Deploy แอปพลิเคชันของเราไปยัง Remote Server โดยใช้ SSH ครับ ในตัวอย่างนี้ เราจะสมมติว่าคุณมี Server ที่สามารถเข้าถึงได้ด้วย SSH และมี Node.js ติดตั้งอยู่แล้ว

ก่อนอื่น เราจำเป็นต้องตั้งค่า SSH Key ใน GitHub Secrets เพื่อความปลอดภัยครับ

  1. สร้าง SSH Key Pair:

    บนเครื่องของคุณ สร้าง SSH Key Pair ใหม่ (หากยังไม่มี) โดยใช้คำสั่ง:

    ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/github_deploy_key

    อย่าใส่ Passphrase เพื่อให้ GitHub Actions สามารถใช้ Key ได้โดยอัตโนมัติครับ

  2. เพิ่ม Public Key ไปยัง Server:

    คัดลอกเนื้อหาของไฟล์ github_deploy_key.pub ไปยังไฟล์ ~/.ssh/authorized_keys บน Server ปลายทางของคุณ:

    ssh-copy-id -i ~/.ssh/github_deploy_key.pub user@your_server_ip
# หรือคัดลอกด้วยมือ:
# cat ~/.ssh/github_deploy_key.pub | ssh user@your_server_ip 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
  3. เพิ่ม Private Key เป็น GitHub Secret:

    • ไปที่ GitHub Repository ของคุณ > Settings > Secrets and variables > Actions > New repository secret.
    • ตั้งชื่อ Secret ว่า SSH_PRIVATE_KEY
    • คัดลอกเนื้อหาทั้งหมดของไฟล์ github_deploy_key (ที่เป็น Private Key) และวางลงในช่อง “Secret value”
    • (Optional) เพิ่ม Secret สำหรับ Username ของ Server เช่น SSH_USERNAME และ IP ของ Server เช่น SSH_HOST

เมื่อตั้งค่า Secrets เสร็จแล้ว เราก็พร้อมที่จะสร้าง Workflow สำหรับ Deploy ครับ เราจะสร้าง Workflow ใหม่ชื่อ deploy.yml หรือจะต่อท้ายในไฟล์ ci.yml เดิมก็ได้ครับ สำหรับบทความนี้เราจะแยกเป็นอีก Job หนึ่งในไฟล์ ci.yml เดิม เพื่อให้ Workflow เป็นแบบต่อเนื่อง

# .github/workflows/ci.yml (เพิ่ม Job deploy ต่อจาก build-and-test)

name: Node.js CI/CD Pipeline

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

jobs:
  build-and-test:
    name: Build and Test Node.js App
    runs-on: ubuntu-latest

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

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

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      # Step สำหรับอัปโหลด Artifacts เพื่อให้ Job deploy สามารถนำไปใช้ได้
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: node-app-build
          path: . # อัปโหลดทั้งโฟลเดอร์โปรเจกต์ หรือเฉพาะ build folder ถ้ามี

  # Job ที่ 2: deploy-to-server
  deploy-to-server:
    name: Deploy to Production Server
    runs-on: ubuntu-latest
    needs: build-and-test # Job นี้จะรันหลังจาก 'build-and-test' สำเร็จเท่านั้น

    steps:
      # Step 1: ดาวน์โหลด Artifacts ที่สร้างจาก Job ก่อนหน้า
      - name: Download build artifacts
        uses: actions/download-artifact@v4
        with:
          name: node-app-build
          path: ./app-to-deploy # ดาวน์โหลดมาเก็บไว้ในโฟลเดอร์ app-to-deploy

      # Step 2: ตั้งค่า SSH Agent และเพิ่ม Private Key
      # uses: webfactory/[email protected] เป็น Action ที่ช่วยจัดการ SSH key
      - name: Set up SSH Agent
        uses: webfactory/[email protected]
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }} # ใช้ SSH Private Key จาก GitHub Secrets

      # Step 3: เพิ่ม SSH Host Key เพื่อหลีกเลี่ยงข้อความยืนยัน (Host Key Verification)
      - name: Add SSH Host Key
        run: |
          mkdir -p ~/.ssh
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      # Step 4: Deploy ไฟล์ไปยัง Server
      # ใช้ rsync ผ่าน SSH เพื่อคัดลอกไฟล์
      - name: Deploy with rsync
        run: |
          rsync -avz --delete ./app-to-deploy/ ${{ secrets.SSH_USERNAME }}@${{ secrets.SSH_HOST }}:/var/www/my-node-app/
          # หลังจากการ Deploy คุณอาจต้องการ Restart เซอร์วิสบน Server
          ssh ${{ secrets.SSH_USERNAME }}@${{ secrets.SSH_HOST }} "cd /var/www/my-node-app && npm install && pm2 restart my-node-app"
        env:
          SSH_ASKPASS: "true" # เพื่อให้ rsync ไม่ขอรหัสผ่าน

คำอธิบาย Workflow เพิ่มเติมสำหรับ Job `deploy-to-server`:

  • `needs: build-and-test`: Job นี้จะถูกรันก็ต่อเมื่อ Job `build-and-test` สำเร็จเท่านั้น
  • `actions/download-artifact@v4`: Action สำหรับดาวน์โหลด Artifact ที่ถูกอัปโหลดโดย Job `build-and-test`
  • `webfactory/[email protected]`: Action ที่ช่วยจัดการ SSH Key ทำให้เราสามารถใช้ SSH Private Key ที่เก็บไว้ใน GitHub Secrets ได้อย่างปลอดภัย
  • `ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts`: เป็นการเพิ่ม Host Key ของ Server ปลายทางลงใน `known_hosts` เพื่อหลีกเลี่ยงข้อความเตือนเรื่อง Host Key Verification เมื่อเชื่อมต่อ SSH ครั้งแรกครับ
  • `rsync -avz –delete …`: ใช้คำสั่ง `rsync` ผ่าน SSH เพื่อคัดลอกไฟล์จาก Runner ไปยัง Server โดย `avz` คือ archive mode, verbose, และ compress ส่วน `–delete` จะลบไฟล์บน Server ที่ไม่มีอยู่ใน Source (ระวังการใช้งาน)
  • `ssh … “…”`: หลังจากคัดลอกไฟล์เสร็จ เราสามารถรันคำสั่งบน Server ผ่าน SSH ได้ เช่น `npm install` เพื่อติดตั้ง Dependencies ใหม่บน Server และ `pm2 restart my-node-app` เพื่อ Restart แอปพลิเคชัน (สมมติว่าคุณใช้ PM2 ในการรัน Node.js app ของคุณ)
  • `env: SSH_ASKPASS: “true”`: เป็นการตั้งค่าเพิ่มเติมเพื่อช่วยให้ `rsync` หรือ `ssh` ไม่ติดปัญหาการขอรหัสผ่านครับ

เมื่อคุณ Push ไฟล์ Workflow นี้ขึ้น GitHub ทุกครั้งที่โค้ดถูก Push ไปยัง `main` branch Workflow จะทำการ Build, Test และหากสำเร็จ ก็จะทำการ Deploy โค้ดไปยัง Server ของคุณโดยอัตโนมัติครับ

3.4. ตัวอย่างที่ 3: CD Pipeline สำหรับ Deploy ไปยัง Cloud Storage (AWS S3)

การ Deploy ไปยัง Cloud Storage เช่น AWS S3 เป็นวิธีที่นิยมสำหรับ Static Websites หรือ Frontend Applications ที่ถูก Build เป็น Static Files ครับ ในตัวอย่างนี้ เราจะสาธิตการ Deploy ไปยัง AWS S3

การเตรียมตัวสำหรับ AWS S3 Deployment:

  1. สร้าง S3 Bucket:

    สร้าง S3 Bucket ใน AWS Console ของคุณ และตั้งค่าให้เป็น Static Website Hosting (ถ้าเป็นเว็บไซต์)

  2. สร้าง IAM User และ Policy:

    สร้าง IAM User ใน AWS ที่มีสิทธิ์ในการเขียน (PutObject), ลบ (DeleteObject) และอ่าน (GetObject) ใน S3 Bucket ที่คุณสร้างไว้ครับ (ควรจำกัดสิทธิ์ให้แคบที่สุดเท่าที่จำเป็น)

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::your-s3-bucket-name/*",
                "arn:aws:s3:::your-s3-bucket-name"
            ]
        }
    ]
}
  3. เพิ่ม AWS Credentials เป็น GitHub Secrets:

    • ไปที่ GitHub Repository ของคุณ > Settings > Secrets and variables > Actions > New repository secret.
    • ตั้งชื่อ Secret ว่า AWS_ACCESS_KEY_ID และใส่ค่า Access Key ID
    • ตั้งชื่อ Secret ว่า AWS_SECRET_ACCESS_KEY และใส่ค่า Secret Access Key
    • (Optional) เพิ่ม Secret สำหรับ AWS Region เช่น AWS_REGION

มาสร้าง Workflow สำหรับ Deploy ไปยัง S3 กันครับ เราจะเพิ่ม Job ใหม่ในไฟล์ ci.yml ของเรา:

# .github/workflows/ci.yml (เพิ่ม Job deploy-to-s3 ต่อจาก build-and-test)

name: Node.js CI/CD Pipeline

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

jobs:
  build-and-test:
    name: Build and Test Node.js App
    runs-on: ubuntu-latest

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

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

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      # (สมมติว่าโปรเจกต์นี้เป็น Frontend และมี build script)
      - name: Build project (if applicable)
        run: npm run build # หรือคำสั่ง build ของคุณ เช่น 'yarn build'

      # อัปโหลด Build Artifacts เพื่อให้ Job deploy สามารถนำไปใช้ได้
      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: static-website-build
          path: build/ # path ของโฟลเดอร์ที่เก็บไฟล์ที่ build แล้ว เช่น 'dist/' หรือ 'public/'

  # Job ที่ 3: deploy-to-s3
  deploy-to-s3:
    name: Deploy to AWS S3
    runs-on: ubuntu-latest
    needs: build-and-test # Job นี้จะรันหลังจาก 'build-and-test' สำเร็จเท่านั้น

    env:
      AWS_REGION: ap-southeast-1 # กำหนด AWS Region ของคุณ

    steps:
      # Step 1: ดาวน์โหลด Artifacts ที่สร้างจาก Job ก่อนหน้า
      - name: Download build artifacts
        uses: actions/download-artifact@v4
        with:
          name: static-website-build
          path: ./build-output # ดาวน์โหลดมาเก็บไว้ในโฟลเดอร์ build-output

      # Step 2: ตั้งค่า AWS Credentials
      # uses: aws-actions/configure-aws-credentials@v4 เป็น Action ที่ช่วยตั้งค่า AWS CLI
      - 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 }}

      # Step 3: Sync ไฟล์ไปยัง S3 Bucket
      # ใช้ AWS CLI เพื่อ sync ไฟล์
      - name: Deploy static files to S3
        run: |
          aws s3 sync ./build-output/ s3://your-s3-bucket-name --delete
          # --delete จะลบไฟล์ใน S3 bucket ที่ไม่มีอยู่ใน source path (ระวังการใช้งาน)

      # Step 4 (Optional): ล้าง Cache ของ CloudFront (ถ้าใช้)
      - name: Invalidate CloudFront Cache
        if: success() # รันเฉพาะเมื่อ Job นี้สำเร็จ
        run: |
          aws cloudfront create-invalidation --distribution-id YOUR_CLOUDFRONT_DISTRIBUTION_ID --paths "/*"
        env:
          YOUR_CLOUDFRONT_DISTRIBUTION_ID: # <-- ใส่ CloudFront Distribution ID ของคุณ

คำอธิบาย Workflow เพิ่มเติมสำหรับ Job `deploy-to-s3`:

  • `env: AWS_REGION`: เราสามารถกำหนด Environment Variable เฉพาะสำหรับ Job นี้ได้
  • `aws-actions/configure-aws-credentials@v4`: Action ที่ช่วยตั้งค่า AWS Credentials ให้กับ Runner ทำให้เราสามารถใช้ AWS CLI ใน Step ต่อไปได้
  • `aws s3 sync ...`: คำสั่ง AWS CLI สำหรับ Sync ไฟล์จากโฟลเดอร์ `build-output` ไปยัง S3 Bucket ของคุณ `your-s3-bucket-name`
  • `--delete`: เป็น option ที่สำคัญมาก หากคุณใช้ `--delete` ไฟล์ใน S3 Bucket ที่ไม่มีอยู่ใน Source Path จะถูกลบออก ซึ่งมีประโยชน์ในการล้างไฟล์เก่าที่ไม่จำเป็น แต่ต้องใช้ด้วยความระมัดระวังครับ
  • `aws cloudfront create-invalidation ...` (Optional): หากคุณใช้ CloudFront CDN อยู่หน้า S3 Bucket คุณจะต้องทำการ Invalidate Cache เพื่อให้ผู้ใช้ได้รับเวอร์ชันล่าสุดของเว็บไซต์ครับ

เมื่อคุณ Push ไฟล์ Workflow นี้ขึ้น GitHub ระบบจะทำการ Build, Test และหากสำเร็จ ก็จะทำการ Deploy Static Files ของคุณไปยัง AWS S3 Bucket โดยอัตโนมัติครับ

3.6. การจัดการ Secrets และ Environment Variables อย่างปลอดภัย

ในตัวอย่างข้างต้น เราได้เห็นการใช้ `secrets.SSH_PRIVATE_KEY` และ `secrets.AWS_ACCESS_KEY_ID` ไปแล้ว นี่คือแนวทางปฏิบัติที่สำคัญสำหรับการรักษาความปลอดภัยของข้อมูลที่ละเอียดอ่อนครับ

  • GitHub Secrets:

    สำหรับข้อมูลที่ละเอียดอ่อน เช่น API Keys, Database Passwords, SSH Private Keys ควรเก็บไว้ใน GitHub Secrets ครับ ข้อมูลเหล่านี้จะถูกเข้ารหัสและไม่สามารถถูกแสดงใน Log ของ Workflow ได้

    วิธีตั้งค่า: ไปที่ Repository > Settings > Secrets and variables > Actions > New repository secret

    วิธีเรียกใช้ใน Workflow: ใช้ `secrets.SECRET_NAME`

  • Environment Variables:

    สำหรับข้อมูลที่ไม่ใช่ความลับ หรือค่าที่อาจแตกต่างกันไปในแต่ละสภาพแวดล้อม (เช่น ชื่อ Bucket S3, Region) สามารถกำหนดเป็น Environment Variables ได้ครับ

    • Global Env: กำหนดที่ระดับ Workflow (ใต้ `on:`)
    • Job-specific Env: กำหนดที่ระดับ Job (ใต้ `job_name:`)
    • Step-specific Env: กำหนดที่ระดับ Step (ใต้ `step_name:`)

    วิธีเรียกใช้ใน Workflow: ใช้ `env.VARIABLE_NAME` หรือ `$VARIABLE_NAME` ในคำสั่ง `run`

    # ตัวอย่างการใช้ Environment Variables
name: Example Workflow

on: [push]

env:
  GLOBAL_VAR: "Hello from global"

jobs:
  my_job:
    runs-on: ubuntu-latest
    env:
      JOB_VAR: "Hello from job"
    steps:
      - name: Use environment variables
        run: |
          echo "Global variable: ${{ env.GLOBAL_VAR }}"
          echo "Job variable: $JOB_VAR" # ใช้ $ ได้ใน bash
        env:
          STEP_VAR: "Hello from step"

การใช้ GitHub Secrets อย่างถูกต้องเป็นสิ่งสำคัญอย่างยิ่งในการป้องกันข้อมูลสำคัญของคุณจากการรั่วไหลครับ

4. เคล็ดลับและแนวทางปฏิบัติที่ดีที่สุด (Best Practices) สำหรับ GitHub Actions CI/CD

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

4.1. การใช้ Reusable Workflows และ Composite Actions

เมื่อโปรเจกต์ของคุณมีขนาดใหญ่ขึ้น หรือคุณมีหลาย Repository ที่ต้องการ Pipeline ที่คล้ายคลึงกัน การซ้ำโค้ด Workflow อาจกลายเป็นปัญหาได้ GitHub Actions มีวิธีแก้ไขปัญหานี้:

  • Reusable Workflows:

    อนุญาตให้คุณกำหนด Workflow หนึ่งเป็น Template และเรียกใช้จาก Workflow อื่นๆ ได้ครับ เหมาะสำหรับ Job ที่ซับซ้อนและมีหลาย Steps ที่ต้องใช้ซ้ำๆ ในหลายๆ Repository หรือใน Workflow เดียวกันแต่เป็นคนละ Job ครับ

    ประโยชน์: ลดการซ้ำซ้อน, ทำให้ Workflow อ่านง่ายขึ้น, บำรุงรักษาง่ายขึ้น (แก้ที่เดียวใช้ได้หลายที่), และทำให้เกิดความสอดคล้องกัน

    ตัวอย่าง: คุณสามารถมี Workflow สำหรับ Build & Test Node.js โดยเฉพาะใน Repository กลาง และเรียกใช้จาก Repository ของแอปพลิเคชัน Frontend/Backend ได้

    อ่านเพิ่มเติมเกี่ยวกับ Reusable Workflows

  • Composite Actions:

    เป็นวิธีที่ดีในการรวมหลาย Steps เข้าเป็น Action เดียวครับ เหมาะสำหรับ Tasks ย่อยๆ ที่ต้องทำซ้ำๆ ภายใน Job เดียวกัน หรือในหลาย Jobs ที่อยู่ใน Workflow เดียวกัน

    ประโยชน์: ทำให้ Job สั้นลงและอ่านง่ายขึ้น, ซ่อนความซับซ้อนของหลาย Steps ไว้ใน Action เดียว

    ตัวอย่าง: คุณอาจสร้าง Composite Action ที่รวม Step "Install Dependencies" และ "Run Lint" เข้าด้วยกัน

4.2. การจัดการ Environment และ Environment Protection Rules

GitHub Actions ช่วยให้คุณสามารถกำหนด "Environments" สำหรับ Workflow ของคุณได้ เช่น `Development`, `Staging`, `Production` ซึ่งมีประโยชน์อย่างมากในการจัดการการ Deploy และการตั้งค่าที่แตกต่างกันในแต่ละสภาพแวดล้อม

  • การกำหนด Environment:

    คุณสามารถระบุ `environment:` ในระดับ Job เพื่อให้ Job นั้นรันในสภาพแวดล้อมที่กำหนด

    jobs:
  deploy-production:
    runs-on: ubuntu-latest
    environment: production # ระบุ Environment
    steps:
      # ... deploy steps ...
  • Protection Rules:

    สำหรับแต่ละ Environment คุณสามารถตั้งค่า "Protection Rules" ได้ที่ Repository Settings > Environments ครับ เช่น:

    • Required reviewers: กำหนดให้ต้องมีผู้ตรวจสอบ (Reviewer) อนุมัติก่อนที่ Job จะรันใน Environment นั้น (เช่น Production)
    • Wait timer: กำหนดเวลาที่ต้องรอ (เช่น 30 นาที) ก่อนที่ Job จะเริ่มรัน
    • Branch protection: กำหนดให้ Job รันได้เฉพาะจาก Branch ที่กำหนดเท่านั้น

    ฟีเจอร์นี้ช่วยเพิ่มความปลอดภัยและควบคุมกระบวนการ Deploy ไปยังสภาพแวดล้อมที่สำคัญได้อย่างมีประสิทธิภาพครับ

4.3. การเพิ่มความปลอดภัยให้กับ Workflow

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

  • ใช้ GitHub Secrets อย่างเคร่งครัด:

    ดังที่กล่าวไปแล้ว ห้าม Hardcode ข้อมูลที่ละเอียดอ่อนในไฟล์ Workflow หรือในโค้ด ใช้ GitHub Secrets เสมอครับ

  • จำกัดสิทธิ์ของ GITHUB_TOKEN:

    GitHub Actions มี `GITHUB_TOKEN` ที่ถูกสร้างขึ้นโดยอัตโนมัติสำหรับแต่ละ Workflow Run ซึ่งมีสิทธิ์ในการทำสิ่งต่างๆ ใน Repository โดยค่าเริ่มต้นมีสิทธิ์ค่อนข้างกว้างขวาง

    คุณสามารถจำกัดสิทธิ์ของ Token นี้ได้ในระดับ Workflow หรือ Job:

    permissions:
  contents: read # อนุญาตให้อ่านโค้ดเท่านั้น
  pull-requests: write # อนุญาตให้เขียน Pull Request ได้

    ควรให้สิทธิ์เท่าที่จำเป็น (Least Privilege Principle) เพื่อลดความเสี่ยงหาก Workflow ถูกโจมตีครับ

  • ตรวจสอบ Actions จาก Third-party:

    ก่อนใช้ Actions จาก GitHub Marketplace ควรตรวจสอบความน่าเชื่อถือของผู้พัฒนา, ตรวจสอบโค้ด Source (ถ้าเป็นไปได้), และใช้เวอร์ชันที่แน่นอน (เช่น `v4` แทนที่จะเป็น `main`) เพื่อป้องกันการเปลี่ยนแปลงที่ไม่คาดคิด

  • ใช้ Trusted Actions:

    ควรใช้ Actions ที่เป็นทางการจาก GitHub (เช่น `actions/checkout`, `actions/setup-node`) หรือจากผู้ให้บริการ Cloud ที่เป็นที่ยอมรับ

  • การสแกนความปลอดภัย:

    รวม Steps สำหรับการสแกนโค้ดเพื่อหาช่องโหว่ (Static Application Security Testing - SAST) หรือการสแกน Dependencies (Software Composition Analysis - SCA) เข้าไปใน CI Pipeline ของคุณครับ

4.4. การลดเวลาและค่าใช้จ่ายในการรัน Workflow

Workflow ที่รันเร็วขึ้น ไม่เพียงแต่ช่วยประหยัดเวลาของนักพัฒนา แต่ยังช่วยลดค่าใช้จ่ายในการใช้ GitHub-hosted Runners ด้วยครับ

  • Caching Dependencies:

    การติดตั้ง Dependencies (เช่น `npm install`, `composer install`, `pip install`) มักใช้เวลานาน คุณสามารถใช้ `actions/cache` เพื่อ Cache Dependencies เหล่านี้ได้ ทำให้การรันครั้งต่อๆ ไปเร็วขึ้นอย่างมาก

          - name: Cache Node.js modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
  • ใช้ Matrix Strategy:

    หากคุณต้องการทดสอบโค้ดกับ Node.js หลายเวอร์ชัน หรือระบบปฏิบัติการหลายตัว คุณสามารถใช้ Matrix Strategy เพื่อรัน Jobs แบบขนานได้ ซึ่งช่วยลดเวลาการทดสอบโดยรวม

    jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18, 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
  • Self-hosted Runners:

    หากคุณมี Workload ที่สูงมาก หรือต้องการใช้ Hardware ที่เฉพาะเจาะจง การใช้ Self-hosted Runners อาจคุ้มค่ากว่าในระยะยาว เพราะไม่ต้องเสียค่าใช้จ่ายต่อนาทีของ GitHub-hosted Runners ครับ

  • จำกัด Event Trigger:

    ทริกเกอร์ Workflow เฉพาะเมื่อจำเป็นเท่านั้น เช่น รัน CI บน Pull Request แต่รัน CD เฉพาะบน Merge ไปยัง `main` branch ครับ

4.5. การตรวจสอบและแก้ไขปัญหา Workflow

บางครั้ง Workflow อาจล้มเหลว การรู้วิธีตรวจสอบและแก้ไขปัญหาเป็นสิ่งสำคัญครับ

  • ตรวจสอบ Log:

    ทุก Workflow Run จะมี Log ละเอียดในแท็บ "Actions" ของ GitHub Repository เข้าไปดู Log ของแต่ละ Step เพื่อระบุว่าเกิดข้อผิดพลาดที่ใดครับ

  • เพิ่ม Step สำหรับ Debug:

    คุณสามารถเพิ่ม Step ชั่วคราวใน Workflow เพื่อปริ้นต์ Environment Variables, แสดงรายการไฟล์, หรือรันคำสั่ง Debugging อื่นๆ ได้

          - name: Debug Info
        if: always() # รันเสมอ ไม่ว่าจะสำเร็จหรือไม่
        run: |
          echo "Current directory: $(pwd)"
          ls -la
          printenv
  • ใช้ `if` Condition:

    คุณสามารถใช้ `if` Condition เพื่อควบคุมว่า Step หรือ Job ใดจะรันเมื่อใด เช่น รัน Step Debugging เฉพาะเมื่อ Workflow ล้มเหลว (`if: failure()`) หรือเมื่อสำเร็จ (`if: success()`) ครับ

  • อ่านเอกสาร:

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

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

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

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

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

คุณสมบัติ GitHub Actions Jenkins GitLab CI/CD CircleCI Travis CI
ประเภทการติดตั้ง Cloud-hosted (GitHub-hosted Runners), Self-hosted Runners Self-hosted (ต้องติดตั้งและดูแลเอง), Cloud-hosted (ผ่านผู้ให้บริการ) Cloud-hosted (GitLab.com), Self-hosted (GitLab Enterprise) Cloud-hosted, Self-hosted (สำหรับ Enterprise) Cloud-hosted
การผนวกรวมกับ VCS ผนวกรวมกับ GitHub โดยตรง รองรับ Git, SVN และอื่นๆ (ผ่าน Plugins) ผนวกรวมกับ GitLab โดยตรง ผนวกรวมกับ GitHub, Bitbucket ผนวกรวมกับ GitHub, Bitbucket
การกำหนด Workflow ไฟล์ YAML (.github/workflows/) ไฟล์ Jenkinsfile (Groovy DSL), GUI ไฟล์ .gitlab-ci.yml ไฟล์ .circleci/config.yml ไฟล์ .travis.yml
Marketplace/Plugins GitHub Marketplace (Actions) จำนวนมาก Plugins จำนวนมหาศาล Templates และ Components Orbs (Reusable configurations) Add-ons และ Build Stages
ความยืดหยุ่น สูง (Workflows, Jobs, Steps, Matrix, Environments) สูงมาก (ปรับแต่งได้ทุกอย่างด้วย Plugins) สูง (Pipelines, Jobs, Stages, Rules) สูง (Workflows, Jobs, Orbs) ปานกลาง-สูง (Stages, Jobs)
การจัดการ Secrets GitHub Secrets Credentials Plugin, Vault Integration CI/CD Variables, Vault Integration Contexts (Encrypted Environment Variables) Environment Variables (Encrypted)
Self-hosted Runners มี เป็นหลัก มี มี (สำหรับ Enterprise) ไม่มี
ราคา ฟรีสำหรับ Public Repo, มีนาทีฟรีสำหรับ Private Repo, จ่ายตามการใช้งาน (นาที/Runner) ฟรี (Open Source) แต่มีค่าใช้จ่ายในการดูแล Server ฟรีสำหรับ Public/Private Repo (จำกัดนาที), จ่ายตามการใช้งาน/Tier ฟรีสำหรับ Public/Private Repo (จำกัดนาที), จ่ายตามการใช้งาน ฟรีสำหรับ Public Repo, จ่ายตามการใช้งานสำหรับ Private Repo
ความซับซ้อนในการตั้งค่า ปานกลาง (YAML) สูง (ติดตั้ง, Config Plugins) ปานกลาง (YAML) ปานกลาง (YAML

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

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

Related Articles
จัดส่งรวดเร็วส่งด่วนทั่วประเทศ
รับประกันสินค้าเคลมง่าย มีใบรับประกัน
ผ่อนชำระได้บัตรเครดิต 0% สูงสุด 10 เดือน
สะสมแต้ม รับส่วนลดส่วนลดและคะแนนสะสม

ติดต่อเรา | LINE: @siamlancard

Facebook | YouTube | LINE OA

เว็บในเครือ: SiamCafe.net | iCafeForex.com | Siam2R.com | XMSignal.com

© 2026 SiamLancard — จำหน่ายการ์ดแลน อุปกรณ์ Server และเครื่องพิมพ์ใบเสร็จ

SiamLancard
Logo
Shopping cart