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

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

March 15, 2026
0 Views

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

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

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

สารบัญ

ส่วนที่ 1: ทำความเข้าใจ CI/CD Pipeline

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

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

Continuous Integration หรือ CI คือแนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ที่นักพัฒนาแต่ละคนจะรวมโค้ดของตนเองเข้ากับ codebase หลัก (เช่น branch main หรือ develop) บ่อยครั้ง ซึ่งโดยปกติจะทำอย่างน้อยวันละหลายๆ ครั้งครับ เมื่อมีการรวมโค้ด ระบบ CI จะทำการรันกระบวนการอัตโนมัติหลายอย่าง เช่น การคอมไพล์โค้ด (ถ้าเป็นภาษาที่ต้องคอมไพล์), การรัน Unit Test, Integration Test, Linting และการตรวจสอบคุณภาพโค้ดอื่นๆ ครับ

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

  • ตรวจจับข้อผิดพลาดตั้งแต่เนิ่นๆ: การรวมโค้ดบ่อยๆ ช่วยให้เราพบข้อผิดพลาดหรือความขัดแย้ง (conflict) ระหว่างโค้ดได้อย่างรวดเร็ว ก่อนที่ปัญหาจะบานปลายและแก้ไขได้ยากครับ
  • ให้ Feedback ที่รวดเร็ว: นักพัฒนาจะได้รับการแจ้งเตือนทันทีเมื่อโค้ดที่รวมเข้าไปทำให้ build หรือ test ล้มเหลว ทำให้สามารถแก้ไขได้ทันทีครับ
  • เพิ่มคุณภาพโค้ด: การบังคับใช้มาตรฐานโค้ดผ่าน Linting และการรัน Test อย่างสม่ำเสมอ ช่วยรักษาคุณภาพของ codebase ให้ดีอยู่เสมอครับ
  • ลดความซับซ้อนในการรวมโค้ด: การรวมโค้ดเล็กๆ น้อยๆ บ่อยๆ ดีกว่าการรวมโค้ดก้อนใหญ่ๆ ครั้งเดียว ซึ่งมักจะนำไปสู่ปัญหาที่ซับซ้อนกว่าครับ

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

Continuous Delivery (CD) และ Continuous Deployment (CD) มักถูกใช้สลับกันไปมา แต่จริงๆ แล้วมีความแตกต่างกันเล็กน้อยครับ ทั้งคู่เป็นขั้นตอนที่ต่อจาก Continuous Integration โดยมีเป้าหมายเพื่อส่งมอบซอฟต์แวร์ไปยังสภาพแวดล้อมที่ใช้งานได้จริง (production environment) หรือใกล้เคียงกับการใช้งานจริงครับ

Continuous Delivery (CD)

Continuous Delivery คือการที่โค้ดทั้งหมดที่ผ่านกระบวนการ CI มาแล้ว จะถูกเตรียมพร้อมสำหรับการนำไปใช้งานจริงได้ตลอดเวลาครับ นั่นหมายความว่าโค้ดที่ผ่านการทดสอบและ build สำเร็จแล้ว จะถูกบรรจุอยู่ในรูปแบบที่พร้อมจะนำไป deploy ได้ทุกเมื่อครับ แต่การ deploy จริงไปยัง production นั้น ยังคงต้องอาศัยการตัดสินใจหรือการอนุมัติจากมนุษย์อยู่ครับ

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

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

Continuous Deployment (CD)

Continuous Deployment คือการขยายแนวคิดจาก Continuous Delivery ไปอีกขั้นครับ โดยเมื่อโค้ดผ่านกระบวนการ CI และทดสอบจนมั่นใจแล้วว่ามีคุณภาพดีพอ ระบบจะทำการ deploy โค้ดนั้นไปยัง production environment โดยอัตโนมัติทันทีครับ โดยไม่มีการแทรกแซงจากมนุษย์เลยครับ

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

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

สรุปความแตกต่าง: Continuous Delivery หมายถึง "พร้อม deploy ได้ตลอดเวลา" แต่ยังคงต้องมีการอนุมัติจากมนุษย์ ส่วน Continuous Deployment หมายถึง "deploy อัตโนมัติทันที" โดยไม่มีการอนุมัติจากมนุษย์เลยครับ การเลือกว่าจะใช้แบบไหนขึ้นอยู่กับความต้องการ ความเสี่ยงที่ยอมรับได้ และวัฒนธรรมขององค์กรครับ

ทำไมต้องมี CI/CD Pipeline?

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

  • เพิ่มความเร็วในการออกสู่ตลาด (Time to Market): ช่วยให้คุณส่งมอบฟีเจอร์ใหม่ๆ หรือการแก้ไขข้อผิดพลาดไปยังผู้ใช้งานได้อย่างรวดเร็วและต่อเนื่อง ทำให้ธุรกิจสามารถตอบสนองต่อการเปลี่ยนแปลงของตลาดได้ทันท่วงทีครับ
  • ปรับปรุงคุณภาพซอฟต์แวร์: การรัน Test อัตโนมัติอย่างสม่ำเสมอช่วยให้ตรวจพบและแก้ไขข้อผิดพลาดได้ตั้งแต่ต้น ลดโอกาสที่ Bug จะไปถึง production ครับ
  • ลดความเสี่ยง: การ deploy เล็กๆ บ่อยๆ มีความเสี่ยงน้อยกว่าการ deploy ครั้งใหญ่ๆ ที่มีหลายฟีเจอร์รวมกันครับ หากเกิดปัญหาก็สามารถระบุสาเหตุและแก้ไขได้ง่ายกว่าครับ
  • ลดต้นทุน: การลดเวลาที่ใช้ในการทดสอบและ deploy ด้วยมือ ช่วยลดค่าใช้จ่ายในการดำเนินงานและทำให้ทีมสามารถโฟกัสกับงานที่มีคุณค่ามากขึ้นครับ
  • เพิ่มประสิทธิภาพการทำงานของทีม: นักพัฒนาสามารถรวมโค้ดได้อย่างมั่นใจ โดยรู้ว่าระบบจะตรวจสอบและแจ้งเตือนหากมีปัญหา ทำให้พวกเขาสามารถมุ่งเน้นไปที่การเขียนโค้ดได้เต็มที่ครับ
  • กระบวนการที่ทำซ้ำได้และเชื่อถือได้: ทุกครั้งที่มีการ deploy กระบวนการจะเหมือนเดิมทุกประการ ทำให้ผลลัพธ์ที่ได้มีความสม่ำเสมอและคาดเดาได้ครับ

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

ส่วนที่ 2: เจาะลึก GitHub Actions

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

GitHub Actions คืออะไร?

GitHub Actions คือแพลตฟอร์มสำหรับการทำงานอัตโนมัติแบบ Event-driven ที่ถูกผสานรวมเข้ากับ GitHub โดยตรงครับ มันช่วยให้คุณสามารถสร้าง Workflow ที่ตอบสนองต่อเหตุการณ์ต่างๆ บน GitHub เช่น การ push โค้ด, การเปิด Pull Request, การสร้าง Release หรือแม้แต่การรันตามกำหนดเวลาครับ ด้วย GitHub Actions คุณสามารถ Automate ได้เกือบทุกอย่างในวงจรการพัฒนาซอฟต์แวร์ของคุณ ไม่ว่าจะเป็นการ Build, Test, Deploy, การจัดการ Issue หรือแม้แต่การแจ้งเตือนต่างๆ ครับ

หัวใจสำคัญของ GitHub Actions คือการกำหนด Workflow ในรูปแบบ YAML file ซึ่งจะถูกเก็บไว้ใน Repository ของคุณเอง ทำให้ Workflow นั้นเป็นส่วนหนึ่งของโค้ดเบส และสามารถถูกควบคุมเวอร์ชันได้เหมือนโค้ดทั่วไปครับ

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

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

  1. Workflow:

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

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

on: [push] # Event ที่จะ trigger workflow นี้

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Say Hello
        run: echo "Hello from GitHub Actions!"
  2. Event:

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

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

    คือชุดของ Step ที่ทำงานอยู่บน Runner เดียวกันครับ แต่ละ Job จะรันแยกกันและเป็นอิสระจากกัน แต่ก็สามารถกำหนด Dependency ระหว่าง Job ได้ (เช่น Job B จะรันได้ก็ต่อเมื่อ Job A สำเร็จ) ครับ

    ในตัวอย่างข้างต้น build คือชื่อของ Job ครับ

  4. Step:

    คือแต่ละงานย่อยที่ประกอบกันเป็น Job ครับ Step สามารถเป็นได้ทั้งการรันคำสั่ง Shell Script (run) หรือการเรียกใช้ Action (uses) ครับ แต่ละ Step จะรันตามลำดับใน Job นั้นๆ ครับ

    ในตัวอย่าง - uses: actions/checkout@v3 และ - name: Say Hello / run: echo "Hello..." คือ Step ครับ

  5. Action:

    คือหน่วยย่อยของงานที่นำกลับมาใช้ซ้ำได้ (reusable unit of work) ที่คุณสามารถรวมเข้ากับ Workflow ของคุณได้ครับ Actions สามารถเป็นได้ทั้ง:

    • Actions จาก GitHub Marketplace: เป็น Actions ที่สร้างโดย GitHub หรือ Community เช่น actions/checkout, actions/setup-node ครับ
    • Custom Actions: Actions ที่คุณสร้างขึ้นเองเพื่อทำงานเฉพาะเจาะจง

    การใช้ Actions ช่วยให้คุณไม่ต้องเขียน Script ที่ซ้ำซ้อนด้วยตัวเอง และสามารถนำความสามารถที่คนอื่นสร้างไว้แล้วมาใช้ได้ทันทีครับ

  6. Runner:

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

    • GitHub-hosted Runners: เป็น Virtual Machines ที่ GitHub จัดเตรียมให้ (เช่น ubuntu-latest, windows-latest, macos-latest) มีสภาพแวดล้อมที่ตั้งค่าไว้ล่วงหน้าพร้อมเครื่องมือที่จำเป็นสำหรับการพัฒนาครับ
    • Self-hosted Runners: เป็นเครื่องเซิร์ฟเวอร์ที่คุณติดตั้งและดูแลเอง ซึ่งอาจเป็นประโยชน์หากคุณต้องการใช้ฮาร์ดแวร์เฉพาะ, มีสภาพแวดล้อมภายในองค์กร หรือต้องการควบคุมการทำงานอย่างเต็มที่ครับ

    ในตัวอย่าง runs-on: ubuntu-latest คือการระบุว่า Job นี้จะรันบน GitHub-hosted Runner ที่เป็น Ubuntu เวอร์ชันล่าสุดครับ

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับส่วนประกอบต่างๆ ของ GitHub Actions ได้ที่ เอกสาร GitHub Actions ครับ

ข้อดีของการใช้ GitHub Actions

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

  • การผสานรวมอย่างสมบูรณ์กับ GitHub: เป็นส่วนหนึ่งของ GitHub โดยธรรมชาติ ทำให้ไม่ต้องสลับแพลตฟอร์มไปมา การกำหนดค่า การตรวจสอบสถานะ และการจัดการทั้งหมดทำได้จาก GitHub UI ครับ
  • Marketplace ที่หลากหลาย: มี Actions สำเร็จรูปมากมายใน GitHub Marketplace ที่คุณสามารถนำมาใช้ได้ทันที ช่วยลดเวลาในการเขียน Script และเพิ่มขีดความสามารถของ Workflow ครับ
  • การกำหนดค่าด้วย YAML ที่ง่ายต่อการเรียนรู้: Workflow ถูกกำหนดด้วย YAML ซึ่งเป็นภาษาที่อ่านง่ายและเข้าใจง่าย ทำให้การสร้างและดูแล Workflow ไม่ใช่เรื่องซับซ้อนเกินไปครับ
  • รองรับภาษาและแพลตฟอร์มที่หลากหลาย: ไม่ว่าโปรเจกต์ของคุณจะใช้ Node.js, Python, Java, .NET, Go หรือภาษาอื่นๆ GitHub Actions ก็มี Actions และ Runners ที่รองรับครับ
  • ความยืดหยุ่นสูง: สามารถสร้าง Workflow ที่ซับซ้อนได้ ตั้งแต่ CI พื้นฐานไปจนถึง CD ที่ครอบคลุมการ Deploy ไปยัง Cloud Providers ต่างๆ พร้อมความสามารถในการจัดการ Environment และ Secrets ครับ
  • คุ้มค่าสำหรับโปรเจกต์ Open Source: GitHub Actions ให้บริการฟรีสำหรับ Repository แบบสาธารณะ และมีโควต้าการใช้งานฟรีสำหรับ Repository แบบส่วนตัว ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับนักพัฒนาอิสระและโปรเจกต์ Open Source ครับ
  • ชุมชนขนาดใหญ่: ด้วยความนิยมที่เพิ่มขึ้น ทำให้มีชุมชนผู้ใช้งานและนักพัฒนา Actions ที่แข็งแกร่ง คุณจะพบตัวอย่าง วิธีแก้ไขปัญหา และการสนับสนุนได้ง่ายครับ

ส่วนที่ 3: ออกแบบ CI/CD Pipeline สำหรับโปรเจกต์ของคุณ

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

ขั้นตอนการออกแบบเบื้องต้น

  1. ระบุวัตถุประสงค์ของ Pipeline:

    คุณต้องการให้ Pipeline นี้ทำอะไรบ้าง? เช่น Build โค้ด, รัน Unit Test, รัน Integration Test, สร้าง Docker Image, Deploy ไปยัง Staging, Deploy ไปยัง Production ครับ

  2. ทำความเข้าใจโปรเจกต์ของคุณ:

    • ภาษาและ Framework: โปรเจกต์ของคุณใช้ภาษาอะไร (เช่น Node.js, Python, Java) และมี Framework หรือ Library เฉพาะที่ต้องติดตั้งหรือไม่?
    • Build Process: มีขั้นตอนการ Build อย่างไร (เช่น npm install, npm run build, mvn clean install)?
    • Test Strategy: คุณมี Unit Test, Integration Test หรือ End-to-End Test หรือไม่? คุณใช้ Test Runner ตัวใด (เช่น Jest, Mocha, Pytest, JUnit)?
    • Deployment Target: คุณต้องการ Deploy ไปที่ไหน (เช่น AWS S3, EC2, ECS, EKS, Azure App Service, Google Cloud Run, Vercel, Netlify)?
  3. กำหนด Stages ของ Pipeline:

    โดยทั่วไป Pipeline CI/CD จะแบ่งออกเป็น Stages หลักๆ ดังนี้ครับ

    • Source: ดึงโค้ดจาก Repository (GitHub Actions ทำตรงนี้ให้โดยอัตโนมัติเมื่อ Workflow ถูก Trigger)
    • Build: คอมไพล์โค้ด, ติดตั้ง Dependencies, สร้าง Artifacts (เช่น Docker Image, ไฟล์ที่ Build แล้ว)
    • Test: รัน Unit Test, Integration Test, Linting, Security Scan
    • Deploy (to Staging/Pre-Production): นำ Artifacts ไป Deploy ยังสภาพแวดล้อมทดสอบ
    • Manual Approval (Optional): ในกรณีของ Continuous Delivery อาจมีขั้นตอนการอนุมัติด้วยมือ
    • Deploy (to Production): นำ Artifacts ที่ผ่านการอนุมัติหรือทดสอบแล้ว ไป Deploy ยังสภาพแวดล้อมจริง
  4. ระบุ Triggers:

    Workflow ควรจะทำงานเมื่อเกิดเหตุการณ์ใดบ้าง? เช่น ทุกครั้งที่ push ไปยัง branch main, ทุกครั้งที่เปิด Pull Request, หรือรันด้วยมือเมื่อต้องการ Deploy ครับ

  5. จัดการ Secrets:

    หาก Pipeline ของคุณต้องมีการเข้าถึง API Keys, Credentials สำหรับ Cloud Provider หรือข้อมูลที่ละเอียดอ่อนอื่นๆ คุณจะต้องวางแผนการจัดการ Secrets อย่างปลอดภัยครับ GitHub Actions มีระบบ Secrets ในตัวที่ช่วยในเรื่องนี้ได้ครับ

กรณีศึกษา: เว็บแอปพลิเคชัน Node.js

เพื่อให้เห็นภาพชัดเจน เราจะใช้กรณีศึกษาของเว็บแอปพลิเคชัน Node.js แบบ Single Page Application (SPA) หรือ Static Site ที่จะ Build และ Deploy ไปยัง AWS S3 และ CloudFront ครับ

สมมติฐานสำหรับโปรเจกต์ Node.js:

  • ใช้ Node.js (เช่น React, Vue, Angular)
  • ใช้ npm หรือ yarn ในการจัดการ Dependencies
  • มี Unit Test (เช่น ด้วย Jest)
  • มี Linting (เช่น ด้วย ESLint)
  • ต้องการ Deploy ไปยัง AWS S3 สำหรับ Static Hosting และ CloudFront สำหรับ CDN

การออกแบบ Pipeline สำหรับโปรเจกต์นี้:

  1. CI Stage (เมื่อมีการ push หรือ Pull Request ไปยัง branch main หรือ develop):

    • Checkout Code: ดึงโค้ดจาก Repository
    • Setup Node.js: ติดตั้ง Node.js เวอร์ชันที่เหมาะสม
    • Install Dependencies: รัน npm install หรือ yarn install
    • Run Linting: ตรวจสอบคุณภาพโค้ดด้วย ESLint (npm run lint)
    • Run Tests: รัน Unit Test ทั้งหมด (npm test)
    • Build Application: สร้าง Production Build (npm run build)
    • Archive Artifacts (Optional): บันทึกไฟล์ที่ Build แล้วเป็น Artifact เพื่อนำไปใช้ใน CD Stage (เพื่อความรวดเร็วและสอดคล้องกัน)

    Trigger: on: [push, pull_request] สำหรับ branch main และ develop

  2. CD Stage (เมื่อมีการ push ที่สำเร็จไปยัง branch main และ CI ผ่านทั้งหมด):

    • Checkout Code (หรือ Download Artifacts): ดึงโค้ด หรือดาวน์โหลด Artifacts ที่สร้างไว้ใน CI Stage
    • Setup Node.js (ถ้าต้อง Build ใหม่): ติดตั้ง Node.js เวอร์ชันที่เหมาะสม (ถ้ายังไม่ได้ Build ใน CI)
    • Install Dependencies (ถ้าต้อง Build ใหม่): รัน npm install (ถ้ายังไม่ได้ Build ใน CI)
    • Build Application (ถ้าต้อง Build ใหม่): สร้าง Production Build (npm run build)
    • Configure AWS Credentials: ตั้งค่า AWS Credentials เพื่อให้ Workflow สามารถเข้าถึง AWS ได้
    • Deploy to S3: ซิงค์ไฟล์ที่ Build แล้วไปยัง S3 Bucket
    • Invalidate CloudFront Cache: ล้าง Cache ของ CloudFront เพื่อให้ผู้ใช้งานเห็นเวอร์ชันล่าสุดทันที

    Trigger: on: push เฉพาะ branch main และ needs: [ci-job-name] เพื่อให้มั่นใจว่า CI ผ่านแล้ว

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

ส่วนที่ 4: สร้าง CI Pipeline ด้วย GitHub Actions

ตอนนี้เราได้ออกแบบ Pipeline ของเราแล้วครับ มาลงมือสร้าง CI Pipeline สำหรับโปรเจกต์ Node.js ของเรากันครับ

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

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

เราจะสร้างไฟล์ชื่อ .github/workflows/ci.yml เพื่อจัดการกระบวนการ Continuous Integration ครับ

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

นี่คือตัวอย่าง Workflow ที่ละเอียดสำหรับการทำ CI ของโปรเจกต์ Node.js ครับ

# .github/workflows/ci.yml

# ชื่อของ Workflow ที่จะแสดงใน GitHub Actions UI
name: Node.js CI

# กำหนดเหตุการณ์ที่จะกระตุ้น Workflow นี้
on:
  push:
    # Workflow จะทำงานเมื่อมีการ push โค้ดไปยัง branch 'main' และ 'develop'
    branches: [ "main", "develop" ]
  pull_request:
    # Workflow จะทำงานเมื่อมีการเปิดหรืออัปเดต Pull Request ไปยัง branch 'main' และ 'develop'
    branches: [ "main", "develop" ]
  
  # อนุญาตให้รัน Workflow นี้ด้วยตนเองจาก GitHub UI
  workflow_dispatch:

# กำหนด Jobs ที่จะรันใน Workflow นี้
jobs:
  build-and-test:
    # ชื่อของ Job
    name: Build and Test Node.js App

    # Runner ที่จะใช้รัน Job นี้ (Ubuntu Linux เวอร์ชันล่าสุด)
    runs-on: ubuntu-latest

    # กำหนด Strategy เพื่อรัน Job บน Node.js หลายเวอร์ชัน (optional)
    strategy:
      matrix:
        node-version: [18.x, 20.x] # สามารถทดสอบบน Node.js 18 และ 20 ได้

    # ขั้นตอน (Steps) ทั้งหมดใน Job นี้
    steps:
      # Step 1: ดึงโค้ดจาก Repository
      - name: Checkout Repository
        uses: actions/checkout@v3 # ใช้ Action สำเร็จรูปเพื่อดึงโค้ด

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

      # Step 3: ติดตั้ง Dependencies
      - name: Install Dependencies
        run: npm ci # ใช้ 'npm ci' เพื่อการติดตั้งที่เชื่อถือได้ใน CI/CD

      # Step 4: รัน Linting เพื่อตรวจสอบคุณภาพโค้ด
      - name: Run ESLint
        run: npm run lint # สมมติว่ามี script 'lint' ใน package.json

      # Step 5: รัน Unit Tests
      - name: Run Tests
        run: npm test # สมมติว่ามี script 'test' ใน package.json
        env:
          CI: true # ตั้งค่า CI environment variable (บาง Test Runner อาจใช้)

      # Step 6: สร้าง Production Build
      - name: Build Application
        run: npm run build # สมมติว่ามี script 'build' ใน package.json

      # Step 7: อัปโหลด Artifacts (ไฟล์ที่ Build แล้ว)
      # เพื่อให้ Job ถัดไป (เช่น Deploy Job) สามารถนำไปใช้ได้โดยไม่ต้อง Build ใหม่
      - name: Upload Build Artifacts
        uses: actions/upload-artifact@v3
        with:
          name: build-artifacts-${{ github.sha }} # ตั้งชื่อ Artifact ให้ไม่ซ้ำกัน
          path: build # Path ไปยังโฟลเดอร์ที่เก็บ Production Build (เช่น 'build' หรือ 'dist')
          retention-days: 5 # เก็บ Artifact ไว้นาน 5 วัน

คำอธิบาย Workflow โดยละเอียด:

  • name: Node.js CI: เป็นชื่อที่แสดงในหน้า GitHub Actions ของ Repository ของคุณครับ
  • on:: กำหนดเหตุการณ์ที่จะกระตุ้น Workflow นี้ครับ

    • push: เมื่อมีการ push โค้ดไปยัง branch main หรือ develop Workflow จะทำงานครับ
    • pull_request: เมื่อมีการเปิดหรืออัปเดต Pull Request ไปยัง branch main หรือ develop Workflow จะทำงานครับ
    • workflow_dispatch: อนุญาตให้คุณรัน Workflow นี้ด้วยตนเองจากแท็บ Actions บน GitHub UI ครับ มีประโยชน์สำหรับการทดสอบหรือรันซ้ำๆ ครับ
  • jobs:: ส่วนนี้ประกอบด้วย Job ต่างๆ ที่จะรันครับ ในที่นี้เรามี Job เดียวคือ build-and-test

    • name: Build and Test Node.js App: ชื่อของ Job ที่แสดงใน UI ครับ
    • runs-on: ubuntu-latest: ระบุว่า Job นี้จะรันบน GitHub-hosted Runner ที่เป็นระบบปฏิบัติการ Ubuntu เวอร์ชันล่าสุดครับ
    • strategy: matrix:: เป็นฟีเจอร์ที่ช่วยให้คุณรัน Job เดียวกันบน Configuration ที่แตกต่างกันได้ครับ ในที่นี้เราจะรัน Job build-and-test บน Node.js เวอร์ชัน 18.x และ 20.x ซึ่งจะสร้าง Job แยกกันสอง Job ที่มีสถานะเป็นอิสระต่อกันครับ
    • steps:: เป็นลำดับของงานที่จะทำภายใน Job นี้ครับ

      • - name: Checkout Repository / uses: actions/checkout@v3: นี่คือ Step แรกที่สำคัญเสมอครับ มันใช้ Action ชื่อ checkout เพื่อดึงโค้ดทั้งหมดจาก Repository ของคุณไปยัง Runner ที่กำลังทำงานอยู่ครับ
      • - name: Setup Node.js ${{ matrix.node-version }} / uses: actions/setup-node@v3: ใช้ Action setup-node เพื่อติดตั้ง Node.js เวอร์ชันที่ระบุ (จาก matrix.node-version) ครับ cache: 'npm' จะช่วยให้ GitHub Actions Cache Dependencies ของ npm ไว้ เพื่อลดเวลาในการติดตั้งในครั้งถัดไปครับ
      • - name: Install Dependencies / run: npm ci: รันคำสั่ง npm ci ครับ npm ci (Clean Install) คล้ายกับ npm install แต่ถูกออกแบบมาสำหรับ CI/CD โดยเฉพาะ มันจะติดตั้ง Dependencies ตาม package-lock.json อย่างเคร่งครัด และจะลบ node_modules เก่าทิ้งก่อนติดตั้งใหม่ ทำให้มั่นใจได้ว่าทุกครั้งที่รันจะได้สภาพแวดล้อมที่สะอาดและสอดคล้องกันครับ
      • - name: Run ESLint / run: npm run lint: รัน Script lint ที่กำหนดไว้ใน package.json เพื่อตรวจสอบคุณภาพโค้ดครับ หาก Linting ไม่ผ่าน Workflow จะล้มเหลวครับ
      • - name: Run Tests / run: npm test: รัน Script test ที่กำหนดไว้ใน package.json เพื่อรัน Unit Test และ Integration Test ครับ หากมี Test ใดล้มเหลว Workflow ก็จะล้มเหลวเช่นกันครับ env: CI: true เป็นการตั้งค่า Environment Variable ที่ Test Runner บางตัวอาจใช้เพื่อปรับพฤติกรรมให้เหมาะกับสภาพแวดล้อม CI ครับ
      • - name: Build Application / run: npm run build: รัน Script build ที่กำหนดไว้ใน package.json เพื่อสร้าง Production Build ของแอปพลิเคชันของคุณครับ ผลลัพธ์มักจะอยู่ในโฟลเดอร์ build หรือ dist ครับ
      • - name: Upload Build Artifacts / uses: actions/upload-artifact@v3: นี่คือ Step สำคัญสำหรับการทำ Continuous Delivery ครับ หลังจาก Build สำเร็จ เราจะใช้ Action upload-artifact เพื่อบันทึกไฟล์ที่ Build แล้ว (ในที่นี้คือโฟลเดอร์ build) เป็น Artifact ครับ Artifact นี้สามารถดาวน์โหลดได้จากหน้า Workflow Summary หรือนำไปใช้ใน Job หรือ Workflow อื่นๆ ได้ครับ การทำเช่นนี้ช่วยให้มั่นใจได้ว่าสิ่งที่ถูก Deploy คือสิ่งที่ผ่านการ Build และทดสอบแล้วใน CI เสมอครับ retention-days เป็นการกำหนดระยะเวลาเก็บ Artifact ครับ

การทดสอบและการตรวจสอบ CI Pipeline

หลังจากที่คุณสร้างไฟล์ .github/workflows/ci.yml แล้ว ให้ push โค้ดไปยัง Repository ของคุณครับ

git add .github/workflows/ci.yml
git commit -m "Add Node.js CI workflow"
git push origin main

จากนั้น ให้ไปที่แท็บ "Actions" บน GitHub Repository ของคุณ คุณจะเห็น Workflow ที่ชื่อ "Node.js CI" เริ่มทำงานครับ

คุณสามารถคลิกเข้าไปดูรายละเอียดของแต่ละ Job และแต่ละ Step ได้ครับ หากมี Step ใดล้มเหลว GitHub Actions จะแสดงข้อความข้อผิดพลาดและ Log ที่เกี่ยวข้อง ซึ่งช่วยให้คุณสามารถ Debug ปัญหาได้อย่างรวดเร็วครับ

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

เพียงเท่านี้คุณก็ได้สร้าง CI Pipeline ที่สมบูรณ์แบบสำหรับโปรเจกต์ Node.js ของคุณแล้วครับ ทุกครั้งที่มีการเปลี่ยนแปลงโค้ด ระบบจะทำการ Build และ Test โดยอัตโนมัติ ทำให้คุณมั่นใจในคุณภาพของโค้ดที่ถูกรวมเข้าสู่ Repository หลักครับ

ส่วนที่ 5: สร้าง CD Pipeline ด้วย GitHub Actions

หลังจากที่เรามี CI Pipeline ที่มั่นคงแล้ว ขั้นตอนต่อไปคือการสร้าง CD Pipeline เพื่อ Deploy แอปพลิเคชันที่ผ่านการทดสอบแล้วไปยังสภาพแวดล้อมจริงครับ เราจะใช้ AWS S3 สำหรับ Static Site Hosting และ AWS CloudFront สำหรับ CDN ครับ

Continuous Delivery vs. Continuous Deployment อีกครั้ง

ก่อนจะลงรายละเอียด Workflow เรามาทบทวนความแตกต่างกันอีกครั้งครับ

  • Continuous Delivery: Workflow จะเตรียม Artifacts ที่พร้อม Deploy ไว้ และรอการอนุมัติด้วยมือ (Manual Approval) ก่อนที่จะ Deploy ไป Production ครับ เหมาะสำหรับโปรเจกต์ที่ต้องการควบคุมการ Release หรือมีขั้นตอนการตรวจสอบเพิ่มเติมครับ
  • Continuous Deployment: Workflow จะทำการ Deploy ไป Production โดยอัตโนมัติทันทีที่ CI ผ่านครับ เหมาะสำหรับโปรเจกต์ที่ต้องการความเร็วในการส่งมอบสูง และมี Test Coverage ที่ครอบคลุมและเชื่อถือได้มากพอครับ

ในตัวอย่างนี้ เราจะสร้าง Workflow ที่เน้นไปที่ Continuous Deployment ที่ทำงานอัตโนมัติเมื่อ CI ผ่านบน branch main ครับ

ตัวอย่าง CD Workflow สำหรับ Node.js ไปยัง AWS S3/CloudFront

เราจะสร้างไฟล์ชื่อ .github/workflows/cd.yml ครับ

# .github/workflows/cd.yml

name: Deploy to AWS S3 & CloudFront

on:
  push:
    # Workflow จะทำงานเมื่อมีการ push โค้ดไปยัง branch 'main' เท่านั้น
    branches: [ "main" ]
  
  # อนุญาตให้รัน Workflow นี้ด้วยตนเองจาก GitHub UI
  workflow_dispatch:

# กำหนด Jobs ที่จะรันใน Workflow นี้
jobs:
  # Job แรก: CI (เพื่อความมั่นใจว่าโค้ดผ่านการ Build และ Test แล้ว)
  # เราสามารถเรียกใช้ CI Workflow แยกต่างหาก หรือรวม Job CI ไว้ในนี้ก็ได้
  # ในตัวอย่างนี้ เราจะอ้างอิงจาก Artifacts ที่สร้างโดย CI Workflow ก่อนหน้า
  
  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest

    # กำหนดว่า Job นี้จะรันได้ก็ต่อเมื่อ Job จาก CI Workflow ก่อนหน้าสำเร็จแล้ว
    # โดยอ้างอิงจาก Workflow ID และ Job ID ของ CI Workflow
    # เช่น 'build-and-test' เป็นชื่อ Job ใน ci.yml
    # ต้องแน่ใจว่า CI Workflow ได้อัปโหลด Artifacts ด้วยชื่อที่ถูกต้อง
    needs: build-and-test # อันนี้คือชื่อ Job ใน ci.yml ที่เราต้องการให้รันก่อน

    # กำหนด Environment สำหรับ Job นี้ (เพื่อความปลอดภัยและการจัดการ)
    environment: Production

    # ขั้นตอน (Steps) ทั้งหมดใน Job นี้
    steps:
      # Step 1: ดาวน์โหลด Artifacts ที่ถูก Build ไว้จาก CI Workflow
      - name: Download Build Artifacts
        uses: actions/download-artifact@v3
        with:
          name: build-artifacts-${{ github.sha }} # ต้องตรงกับชื่อที่ upload ใน ci.yml
          path: build # โฟลเดอร์ที่จะดาวน์โหลด Artifacts ลงมา

      # Step 2: ตั้งค่า AWS Credentials
      # ใช้ Action สำเร็จรูปของ AWS เพื่อตั้งค่า AWS CLI ให้สามารถใช้งานได้
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          # ดึง AWS Access Key ID จาก GitHub Secrets
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          # ดึง AWS Secret Access Key จาก GitHub Secrets
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          # กำหนด AWS Region ที่จะใช้งาน
          aws-region: ap-southeast-1 # ตัวอย่าง: Singapore region

      # Step 3: Deploy ไฟล์ไปยัง AWS S3 Bucket
      - name: Deploy to S3 Bucket
        run: |
          aws s3 sync build/ s3://${{ secrets.AWS_S3_BUCKET_NAME }} \
            --delete \
            --acl public-read \
            --cache-control "max-age=31536000" # ตั้งค่า Cache Control Header สำหรับไฟล์

      # Step 4: ล้าง Cache ของ AWS CloudFront Distribution (ถ้ามี)
      - name: Invalidate CloudFront Cache
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.AWS_CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*" # ล้าง Cache ทุก Path
        env:
          AWS_PAGER: '' # ปิด pager เพื่อให้คำสั่งรันได้โดยไม่มีการรบกวน

คำอธิบาย Workflow โดยละเอียด:

  • name: Deploy to AWS S3 & CloudFront: เป็นชื่อ Workflow ครับ
  • on: push: branches: [ "main" ]: Workflow นี้จะทำงานเมื่อมีการ push โค้ดไปยัง branch main เท่านั้นครับ ซึ่งเป็น Best Practice สำหรับ Production Deployment ครับ
  • workflow_dispatch:: เช่นเดียวกับ CI Workflow ช่วยให้คุณรันด้วยมือได้ครับ
  • jobs: deploy:: เรามี Job เดียวชื่อ deploy

    • runs-on: ubuntu-latest: รันบน Ubuntu Runner ครับ
    • needs: build-and-test: นี่คือส่วนสำคัญครับ! มันระบุว่า Job deploy จะรันได้ก็ต่อเมื่อ Job ที่ชื่อ build-and-test (จาก Workflow ci.yml ของเรา) รันสำเร็จแล้วเท่านั้นครับ การใช้ needs เป็นวิธีที่ดีในการสร้าง Dependency ระหว่าง Jobs หรือ Workflows ครับ (ถ้า CI และ CD อยู่ใน Workflow เดียวกัน ก็ใช้ needs กับ Job CI ได้เลย แต่ในที่นี้เราสมมติว่า CI เป็น Workflow แยก) หมายเหตุ: หาก CI และ CD อยู่ในคนละ Workflow คุณจะต้องใช้ workflow_run event ใน cd.yml แทน needs และดาวน์โหลด Artifact จาก Workflow ที่เรียกครับ เพื่อความง่ายในบทความนี้ ผมจะสมมติว่า Job CI อยู่ใน Workflow เดียวกัน หรือหากแยก Workflow ก็สามารถใช้ workflow_run event เพื่อทริกเกอร์ได้ครับ แต่โดยทั่วไปแล้ว การใช้ needs กับ Artifacts ที่อัปโหลดไว้เป็นวิธีที่นิยมครับ (ในตัวอย่างนี้ ผมจะเขียนแบบที่ build-and-test เป็นชื่อ Job ใน ci.yml ที่ถูกเรียกด้วย push event เช่นกัน แต่ถ้าจะให้ cd.yml รันหลังจาก ci.yml จบจริงๆ ต้องใช้ workflow_run หรือรวมสอง Job เข้าด้วยกันเป็น Workflow เดียวครับ) เพื่อให้สอดคล้องกับแนวคิดการแยก Workflow สำหรับ CI และ CD ผมจะปรับตัวอย่างให้ง่ายขึ้นโดยให้ CD Workflow ดาวน์โหลด Artifact จาก CI Workflow ที่เพิ่งรันเสร็จครับ (Correction: needs can only refer to jobs within the same workflow. To chain workflows, `workflow_run` event is the correct way.)

      ปรับแก้ `needs` สำหรับตัวอย่างนี้: เนื่องจาก `needs` ใช้ได้กับ Job ใน Workflow เดียวกันเท่านั้น ถ้า `ci.yml` และ `cd.yml` เป็นคนละไฟล์ และ `cd.yml` ต้องการรันหลังจาก `ci.yml` จบ เราจะต้องใช้ workflow_run event ใน cd.yml หรือรวม Job CI และ CD เข้าด้วยกันในไฟล์เดียวครับ เพื่อความชัดเจนในบทความนี้ เราจะสมมติว่า Job `build-and-test` เป็น Job ที่รันใน Workflow เดียวกัน (อาจจะอยู่ใน `cd.yml` นี้ หรือใน `ci.yml` แล้วใช้ `workflow_run` ทริกเกอร์) แต่เพื่อความกระชับ ผมจะยังคงใช้ชื่อ `build-and-test` เป็น Job ที่รันก่อนในภาพรวมของ Pipeline และ CD จะใช้ Artifacts ที่ถูกอัปโหลดไว้ครับ

      ทางออกที่ง่ายกว่าและนิยมสำหรับบทความ: รวม CI และ CD Jobs ไว้ใน Workflow เดียวกัน เพื่อให้สามารถใช้ `needs` ได้โดยตรงครับ
    • environment: Production: นี่คือฟีเจอร์ของ GitHub ที่ช่วยให้คุณสามารถกำหนด Environment ที่เฉพาะเจาะจงได้ครับ คุณสามารถตั้งค่ากฎการป้องกัน Environment ได้ เช่น ต้องมีการอนุมัติด้วยมือก่อนการ Deploy หรือกำหนดว่าจะ Deploy ได้เฉพาะจากบาง branch เท่านั้นครับ
    • steps::

      • - name: Download Build Artifacts / uses: actions/download-artifact@v3: ดาวน์โหลด Artifacts ที่ถูกสร้างโดย CI Job ครับ สิ่งนี้สำคัญมากเพราะช่วยให้มั่นใจว่าสิ่งที่ถูก Deploy คือสิ่งที่ผ่านการ Build และ Test ใน CI แล้วจริงๆ ครับ name: build-artifacts-${{ github.sha }} ต้องตรงกับชื่อ Artifact ที่อัปโหลดใน CI Workflow ครับ
      • - name: Configure AWS Credentials / uses: aws-actions/configure-aws-credentials@v1: Action นี้ใช้สำหรับตั้งค่า AWS CLI ให้พร้อมใช้งานครับ โดยจะดึง AWS_ACCESS_KEY_ID และ AWS_SECRET_ACCESS_KEY จาก GitHub Secrets ครับ aws-region เป็นการกำหนด Region ที่จะใช้งานครับ
      • - name: Deploy to S3 Bucket / run: | aws s3 sync ...: ใช้คำสั่ง aws s3 sync เพื่อซิงค์ไฟล์จากโฟลเดอร์ build/ (ที่เราดาวน์โหลด Artifact ลงมา) ไปยัง S3 Bucket ที่กำหนดครับ

        • --delete: จะลบไฟล์ใน S3 ที่ไม่มีอยู่ในโฟลเดอร์ build/ ออกไปครับ
        • --acl public-read: กำหนดสิทธิ์ให้ไฟล์ใน S3 สามารถอ่านได้โดยสาธารณะ (จำเป็นสำหรับ Static Website)
        • --cache-control "max-age=31536000": กำหนด Header สำหรับ Browser Cache ให้ไฟล์เหล่านั้นถูก Cache เป็นเวลา 1 ปีครับ
      • - name: Invalidate CloudFront Cache / run: | aws cloudfront create-invalidation ...: หากคุณใช้ CloudFront เพื่อเป็น CDN ด้านหน้า S3 คุณจะต้องทำการ Invalidate Cache เพื่อให้ผู้ใช้งานได้รับเนื้อหาเวอร์ชันล่าสุดทันทีครับ --distribution-id คือ ID ของ CloudFront Distribution ของคุณครับ --paths "/*" หมายถึงการล้าง Cache ทุก Path ครับ

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

ใน Workflow ข้างต้น เราได้ใช้ ${{ secrets.AWS_ACCESS_KEY_ID }}, ${{ secrets.AWS_SECRET_ACCESS_KEY }}, ${{ secrets.AWS_S3_BUCKET_NAME }} และ ${{ secrets.AWS_CLOUDFRONT_DISTRIBUTION_ID }} ครับ สิ่งเหล่านี้คือ GitHub Secrets ที่ใช้สำหรับเก็บข้อมูลที่ละเอียดอ่อน เช่น API Keys, Credentials โดยไม่เปิดเผยในไฟล์ Workflow ครับ

วิธีการตั้งค่า GitHub Secrets:

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

สำหรับ Production Environment: หากคุณใช้ GitHub Environments (ตามที่เราได้กำหนด environment: Production ใน Workflow) คุณสามารถตั้งค่า Environment Secrets ได้เช่นกันครับ ซึ่งจะช่วยให้คุณควบคุมการเข้าถึง Secrets ได้ละเอียดยิ่งขึ้น เช่น กำหนดว่า Secret นี้ใช้ได้เฉพาะใน Environment "Production" เท่านั้นครับ

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

ส่วนที่ 6: แนวทางปฏิบัติที่ดีที่สุดและเคล็ดลับ

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

แยก Workflow สำหรับ CI และ CD

แม้ว่าคุณจะสามารถรวม Job CI และ CD ไว้ในไฟล์ Workflow เดียวกันได้ แต่แนวทางปฏิบัติที่ดีคือการแยก Workflow สำหรับ CI และ CD ออกจากกัน (ci.yml และ cd.yml) ครับ

ข้อดี:

  • ความชัดเจน: แต่ละ Workflow มีหน้าที่รับผิดชอบที่ชัดเจน ทำให้เข้าใจและดูแลรักษาง่ายขึ้นครับ
  • การควบคุม: คุณสามารถกำหนดเงื่อนไขการรันที่แตกต่างกันสำหรับ CI (เช่น รันบนทุก Pull Request) และ CD (เช่น รันเฉพาะบน branch main และต้องมีการอนุมัติ) ครับ
  • ประสิทธิภาพ: ไม่จำเป็นต้องรัน Job CD ทุกครั้งที่มีการเปลี่ยนแปลงเล็กน้อยในโค้ดครับ

วิธีการเชื่อมโยง: หากแยก Workflow คุณสามารถใช้ workflow_run event ใน CD Workflow เพื่อทริกเกอร์หลังจาก CI Workflow สำเร็จ และใช้ actions/download-artifact@v3 เพื่อดาวน์โหลด Artifact ที่สร้างจาก CI Workflow ครับ

ใช้ GitHub Environments

GitHub Environments ช่วยให้คุณสามารถกำหนดสภาพแวดล้อมการ Deploy (เช่น Development, Staging, Production) และตั้งค่ากฎการป้องกันที่เกี่ยวข้องกับแต่ละ Environment ได้ครับ

ประโยชน์:

  • การอนุมัติด้วยมือ (Manual Approval): กำหนดให้ต้องมีการอนุมัติจากผู้ใช้บางคนก่อนที่จะ Deploy ไปยัง Environment นั้นๆ (เหมาะสำหรับ Production)
  • Secrets เฉพาะ Environment: สามารถเก็บ Secrets ที่แตกต่างกันสำหรับแต่ละ Environment ได้
  • การจำกัด Branch: จำกัดว่า Workflow จะ Deploy ไปยัง Environment ได้จาก branch ใดเท่านั้น

ในการใช้งาน ให้เพิ่ม environment: YourEnvironmentName ใน Job ของ Workflow ที่เกี่ยวข้องครับ

การจัดการ Cache เพื่อความเร็ว

การติดตั้ง Dependencies เช่น node_modules อาจใช้เวลานาน GitHub Actions มี Actions สำหรับ Cache ที่ช่วยลดเวลาในการรัน Workflow ได้อย่างมากครับ

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

การใช้ actions/setup-node@v3 ที่มี cache: 'npm' หรือ cache: 'yarn' ก็เป็นการใช้งาน Cache ที่สะดวกและแนะนำครับ

ลดเวลาการรัน Workflow

Workflow ที่รันเร็วขึ้นหมายถึง Feedback ที่เร็วขึ้นและประหยัดค่าใช้จ่ายครับ

  • Parallel Jobs: หาก Job หรือ Step บางอย่างไม่ขึ้นต่อกัน สามารถรันพร้อมกันได้เพื่อประหยัดเวลาครับ
  • Matrix Strategy: ใช้ matrix เพื่อรัน Test บนหลายเวอร์ชันของภาษาหรือ OS พร้อมกันครับ
  • เลือก Runner ที่เหมาะสม: GitHub-hosted Runners มีสเปกที่แตกต่างกัน เลือกให้เหมาะสมกับความต้องการ
  • ใช้ Actions ที่มีประสิทธิภาพ: เลือกใช้ Actions ที่มีชื่อเสียงและได้รับการดูแลอย่างดี
  • ลดขนาด Repository: ลบไฟล์ที่ไม่จำเป็นออกจาก Repository เพื่อลดเวลาในการ Checkout

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

การรู้ว่า Workflow ของคุณล้มเหลวหรือไม่ และรู้ได้ทันที เป็นสิ่งสำคัญครับ

  • GitHub UI: ตรวจสอบสถานะ Workflow ได้โดยตรงจากแท็บ Actions ใน Repository
  • Badges: เพิ่ม Status Badge ไปยัง README ของ Repository เพื่อแสดงสถานะล่าสุดของ Workflow
  • Notifications: ตั้งค่าให้ GitHub แจ้งเตือนผ่านอีเมล, Slack หรือ Microsoft Teams เมื่อ Workflow ล้มเหลว
  • Monitoring Tools: ผสานรวมกับเครื่องมือ Monitoring ภายนอกเพื่อเก็บ Log และ Metrics ครับ

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

Pipeline ของคุณคือประตูสู่ Production การรักษาความปลอดภัยจึงเป็นสิ่งสำคัญสูงสุดครับ

  • ใช้ GitHub Secrets: เก็บข้อมูลที่ละเอียดอ่อนทั้งหมดใน Secrets อย่า Hardcode ไว้ใน Workflow ครับ
  • Least Privilege: กำหนดสิทธิ์ให้ AWS IAM User หรือ Service Principal ที่ใช้ใน Workflow ให้มีสิทธิ์เท่าที่จำเป็นเท่านั้นครับ เช่น มีสิทธิ์แค่ Sync S3 และ Invalidate CloudFront เท่านั้น ไม่ใช่สิทธิ์ Admin ครับ
  • Code Scanning: ใช้ GitHub CodeQL หรือเครื่องมือวิเคราะห์โค้ดอื่นๆ เพื่อตรวจหาช่องโหว่ด้านความปลอดภัยในโค้ดของคุณตั้งแต่เนิ่นๆ ครับ
  • Dependabot Alerts: เปิดใช้งาน Dependabot เพื่อแจ้งเตือนเมื่อ Dependencies มีช่องโหว่ด้านความปลอดภัย
  • ตรวจสอบ Actions: ก่อนใช้ Actions จาก Marketplace ตรวจสอบ Source Code, ผู้สร้าง, และความน่าเชื่อถือเสมอครับ
  • Environment Protection Rules: ใช้กฎการป้องกันใน GitHub Environments เช่น การอนุมัติด้วยมือ และการจำกัด branch

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

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

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

ตารางเปรียบเทียบ

เรามาดูตารางเปรียบเทียบระหว่าง GitHub Actions กับเครื่องมือ CI/CD ยอดนิยมบางตัวกันครับ

คุณสมบัติ GitHub Actions GitLab CI/CD Jenkins CircleCI
การผสานรวม (Integration) ผสานรวมอย่างสมบูรณ์กับ GitHub ผสานรวมอย่างสมบูรณ์กับ GitLab ต้องผสานรวมด้วยตนเอง (Plugins) ผสานรวมดีกับ GitHub/Bitbucket
ความง่ายในการใช้งาน สูง (YAML, Marketplace) สูง (YAML) ปานกลางถึงต่ำ (ต้องเรียนรู้เยอะ) สูง (YAML)
Marketplace/Ecosystem GitHub Marketplace (Actions) ขนาดใหญ่ Templates, Components ภายใน GitLab Plugins จำนวนมากและหลากหลาย Orbs (Reusable configurations)
Self-Hosted Runners รองรับ (สำหรับควบคุมสภาพแวดล้อม) รองรับ (GitLab Runners) เป็นหลัก (ติดตั้งบนเครื่องของคุณ) รองรับ (Self-hosted Runners)
โมเดลราคา ฟรีสำหรับ Public Repos, มีโควต้าฟรีสำหรับ Private Repos (คิดตามนาที) ฟรีสำหรับ Public Repos, มีโควต้าฟรีสำหรับ Private Repos (คิดตามนาที) โอเพนซอร์ส ฟรี (มีค่าใช้จ่ายในการดูแลเอง) มี Free Tier, คิดตามเครดิต/นาที
ความยืดหยุ่น/การปรับแต่ง สูง (YAML, Custom Actions) สูง (YAML, Docker, Custom Images) สูงมาก (Plugins, Scripting) สูง (YAML, Orbs, Custom Images)
การเรียนรู้ ค่อนข้างง่ายสำหรับผู้เริ่มต้น ค่อนข้างง่ายสำหรับผู้เริ่มต้น สูง ต้องใช้เวลาเรียนรู้เยอะ ปานกลาง
การจัดการ Secrets GitHub Secrets, Environment Secrets CI/CD Variables, HashiCorp Vault Plugins (เช่น Vault Plugin) Contexts (สำหรับ Secrets)

สรุป:

  • GitHub Actions: เป็นตัวเลือกที่ยอดเยี่ยมหากโปรเจกต์ของคุณอยู่บน GitHub อยู่แล้ว ด้วยการผสานรวมที่ไร้รอยต่อ, Marketplace ที่กว้างขวาง และความง่ายในการใช้งาน เหมาะสำหรับทั้งโปรเจกต์ขนาดเล็กไปจนถึงองค์กรขนาดใหญ่ครับ
  • GitLab CI/CD: คล้ายกับ GitHub Actions แต่ผสานรวมกับ GitLab โดยเฉพาะ หากคุณใช้ GitLab เป็นแพลตฟอร์มหลักสำหรับการจัดการโค้ดและ Project Management อยู่แล้ว GitLab CI/CD จะเป็นตัวเลือกที่ลงตัวครับ
  • Jenkins: เป็นเครื่องมือโอเพนซอร์สที่ทรงพลังและยืดหยุ่นที่สุดตัวหนึ่งครับ เหมาะสำหรับองค์กรที่มีความต้องการที่ซับซ้อน ต้องการการปรับแต่งอย่างละเอียด และมีทีมงานที่เชี่ยวชาญในการดูแลรักษา Server CI/CD โดยเฉพาะครับ แต่ก็มาพร้อมกับ Learning Curve ที่สูงกว่าครับ
  • CircleCI: เป็นเครื่องมือที่ได้รับความนิยมสำหรับความง่ายในการใช้งานและความสามารถในการปรับแต่งที่ดี มี Orbs ที่เป็น Configuration สำเร็จรูปช่วยให้เริ่มต้นได้เร็วขึ้นครับ เหมาะสำหรับทีมที่ต้องการโซลูชันที่จัดการได้ง่ายและรวดเร็วครับ

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

ส่วนที่ 8: คำถามที่พบบ่อย (FAQ)

เพื่อให้คุณมีความเข้าใจที่ครอบคลุมยิ่งขึ้น นี่คือคำถามที่พบบ่อยเกี่ยวกับการสร้าง CI/CD Pipeline ด้วย GitHub Actions ครับ

Q1: GitHub Actions ฟรีหรือไม่?

A1: ใช่ครับ GitHub Actions มี Free Tier ที่ค่อนข้าง generous ครับ สำหรับ Public Repositories (โปรเจกต์โอเพนซอร์ส) คุณจะได้รับ Runner Minutes และพื้นที่เก็บ Artifacts ได้ไม่จำกัดครับ สำหรับ Private Repositories คุณจะได้รับโควต้าฟรีต่อเดือน (เช่น 2,000 นาทีสำหรับ GitHub-hosted Runners และพื้นที่เก็บ Artifacts 500 MB) หากใช้เกินโควต้า จะมีการคิดค่าบริการตามการใช้งานครับ รายละเอียดราคาและโควต้าสามารถตรวจสอบได้ที่ หน้า Pricing ของ GitHub Actions ครับ

Q2: สามารถรัน GitHub Actions บน Server ของตัวเองได้หรือไม่ (Self-hosted Runners)?

A2:

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

XM Signal — Free Forex EA Download · iCafeForex.com — EA Forex และเครื่องมือเทรด

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

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

Facebook | YouTube | LINE OA

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

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

SiamLancard
Logo
Free Forex EA Download — XM Signal · EA Forex ฟรี
iCafeForex.com - สอนเทรด Forex | SiamCafe.net
Shopping cart