CI/CD Pipeline คืออะไร GitHub Actions ทำยังไง

บทนำ: CI/CD Pipeline คืออะไร ทำไมถึงสำคัญในโลกยุคใหม่

พื้นฐานความรู้เกี่ยวกับ CI/CD Pipeline

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

# ตัวอย่าง: Build Java project ด้วย Maven
mvn clean install

# ตัวอย่าง: Build Node.js project ด้วย npm
npm install
npm test

Continuous Delivery (CD) และ Continuous Deployment (CD) ต่างกันอย่างไร?

Components หลักของ CI/CD Pipeline

🎬 YouTube @icafefx

วิธีติดตั้งและใช้งาน GitHub Actions เบื้องต้น

ตารางสรุป Terminology ที่ควรรู้

ขั้นตอนการสร้าง Workflow อย่างง่าย

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Run a one-line script
        run: echo Hello, world!
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

คำอธิบาย Code YAML ในตัวอย่าง

ข้อควรรู้เพิ่มเติม

เทคนิคขั้นสูงและการปรับแต่ง GitHub Actions

การใช้ Environment Variables และ Secrets อย่างชาญฉลาด

การจัดการ Environment Variables และ Secrets ถือเป็นหัวใจสำคัญของการทำ CI/CD ให้ปลอดภัยและมีประสิทธิภาพ ลองนึกภาพว่าเราต้องใส่ API key หรือ password ใน workflow ของเราโดยตรง คงไม่ดีแน่ถ้าข้อมูลเหล่านี้รั่วไหลออกไป ดังนั้น GitHub Actions จึงมีระบบจัดการ Secrets ที่เข้ารหัสไว้ ทำให้เราสามารถเรียกใช้ค่าเหล่านี้ใน workflow ได้อย่างปลอดภัย โดยไม่ต้องกังวลว่าใครจะมาแอบดูได้

Environment Variables ก็สำคัญไม่แพ้กัน ช่วยให้เราปรับแต่งการทำงานของ workflow ได้ง่ายขึ้น เช่น กำหนด version ของ software ที่เราต้องการใช้ หรือกำหนดค่า configuration ต่างๆ ที่แตกต่างกันในแต่ละ environment (development, staging, production) ลองดูตัวอย่างการใช้งาน Environment Variables ใน workflow:

name: Deploy to Production

on:
  push:
    branches:
      - main

env:
  NODE_VERSION: 16
  PRODUCTION_HOST: your-production-server.com

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: Deploy to server
        run: |
          echo "Deploying to ${{ env.PRODUCTION_HOST }}"
          # Add your deployment script here

จากตัวอย่างข้างต้น เรากำหนด Environment Variables ชื่อ NODE_VERSION และ PRODUCTION_HOST จากนั้นเราก็สามารถเรียกใช้ค่าเหล่านี้ได้โดยใช้ syntax ${{ env.VARIABLE_NAME }} สะดวกมากๆ เลยใช่ไหมล่ะ

การสร้าง Custom Actions

บางครั้ง workflow ที่เราต้องการ อาจจะซับซ้อนเกินกว่าที่จะใช้ Actions ที่มีอยู่แล้วได้ ในกรณีนี้ เราสามารถสร้าง Custom Actions ของเราเองได้! Custom Actions คือ reusable components ที่เราสามารถนำไปใช้ใน workflow ต่างๆ ได้ ทำให้ code ของเราเป็นระเบียบและง่ายต่อการ maintain

Custom Actions สามารถสร้างได้ 3 แบบหลักๆ คือ:

• JavaScript Actions: เขียนด้วย Node.js เหมาะสำหรับ tasks ที่ต้องการ interaction กับ GitHub API หรือ external services
• Docker Container Actions: Run ใน Docker container ทำให้เราสามารถใช้ language หรือ tools อะไรก็ได้ที่เราต้องการ
• Composite Run Steps Actions: เป็นเหมือน macro ที่รวมเอาหลายๆ step มาไว้ด้วยกัน เหมาะสำหรับ tasks ที่ซ้ำๆ กัน

ตัวอย่างการสร้าง JavaScript Action อย่างง่าย:

1. สร้าง directory สำหรับ Action ของเรา (เช่น my-custom-action)
2. สร้าง file action.yml เพื่อกำหนด metadata ของ Action:

name: 'My Custom Action'
description: 'A simple action that prints a greeting'
inputs:
  who-to-greet:  # id of input
    description: 'Who to greet'
    required: true
    default: 'World'
outputs:
  time: # id of output
    description: 'The time we greeted you'
runs:
  using: 'node16'
  main: 'index.js'

3. สร้าง file index.js ซึ่งเป็น code ของ Action:

const core = require('@actions/core');

try {
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput('time', time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

4. จากนั้นเราก็สามารถใช้ Custom Action นี้ใน workflow ของเราได้:

jobs:
  my_job:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Use my custom action
        uses: ./my-custom-action
        id: greet
        with:
          who-to-greet: 'John Doe'

      - name: Get the output time
        run: echo "The time was ${{ steps.greet.outputs.time }}"

แค่นี้เราก็มี Custom Action ของเราเองแล้ว! ลองเอาไปประยุกต์ใช้กับ tasks ที่ซับซ้อนมากขึ้นได้เลย

การใช้ Matrix Builds เพื่อทดสอบกับหลาย Environments

Matrix Builds เป็น feature ที่ทรงพลังของ GitHub Actions ที่ช่วยให้เราสามารถ run workflow เดียวกันกับหลายๆ environment ได้พร้อมกัน เช่น ทดสอบ code ของเรากับ Node.js หลาย versions หรือกับ operating systems หลายแบบ ช่วยให้เรามั่นใจได้ว่า code ของเราทำงานได้ดีในทุกสภาพแวดล้อม

ตัวอย่างการใช้ Matrix Builds เพื่อทดสอบกับ Node.js versions 14, 16 และ 18:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14, 16, 18]
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

จากตัวอย่างข้างต้น GitHub Actions จะสร้าง jobs ทั้งหมด 3 jobs โดยแต่ละ job จะ run workflow เดียวกัน แต่ใช้ Node.js version ที่แตกต่างกัน เราสามารถดูผลการทดสอบของแต่ละ job ได้แยกกัน ทำให้ง่ายต่อการ identify ปัญหาที่เกิดขึ้นในแต่ละ environment

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

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

GitHub Actions vs. Jenkins

Jenkins ถือเป็นเครื่องมือ CI/CD รุ่นเก๋า ที่ได้รับความนิยมมาอย่างยาวนาน มี plugins มากมายให้เลือกใช้ และมีความยืดหยุ่นสูง แต่ Jenkins ก็มีข้อเสียคือ ต้อง setup และ maintain เอง ทำให้ต้องใช้ทรัพยากรและเวลาในการดูแลรักษาพอสมควร ในขณะที่ GitHub Actions เป็น cloud-based solution ที่ไม่ต้อง setup อะไรมาก ใช้งานง่าย และ integrate กับ GitHub ได้อย่าง seamless

จากตารางจะเห็นได้ว่า GitHub Actions เหมาะสำหรับ project ที่ต้องการความรวดเร็วในการ setup และใช้งานง่าย ส่วน Jenkins เหมาะสำหรับ project ที่ต้องการความยืดหยุ่นสูง และมีการปรับแต่งที่ซับซ้อน

GitHub Actions vs. GitLab CI

GitLab CI เป็น CI/CD solution ที่ integrate อยู่ใน GitLab platform เช่นเดียวกับ GitHub Actions ที่ integrate อยู่ใน GitHub platform ทั้งสองเครื่องมือมีความสามารถใกล้เคียงกัน แต่ GitLab CI มี feature บางอย่างที่ GitHub Actions ยังไม่มี เช่น Auto DevOps ที่ช่วยให้เรา setup CI/CD pipeline ได้อัตโนมัติ

ถ้าเราใช้ GitLab อยู่แล้ว GitLab CI ก็เป็นตัวเลือกที่น่าสนใจ เพราะ integrate กับ GitLab ได้อย่าง seamless แต่ถ้าเราใช้ GitHub อยู่แล้ว GitHub Actions ก็เป็นตัวเลือกที่ดีเช่นกัน

ข้อควรระวังและแนวทางการแก้ไขปัญหา (Troubleshooting)

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

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

• Secrets management: อย่า commit secrets (API keys, passwords) ลงใน repository โดยตรง ให้ใช้ GitHub Secrets หรือ tools อื่นๆ ในการจัดการ secrets
• Dependency management: กำหนด dependencies ให้ชัดเจน เพื่อหลีกเลี่ยงปัญหา dependency conflicts และ ensure ว่า build ของเรา reproducible
• Test coverage: เขียน tests ให้ครอบคลุม code ของเรา เพื่อ detect bugs ก่อนที่จะ deploy ขึ้น production
• Rollback strategy: เตรียมแผน rollback ในกรณีที่ deployment มีปัญหา เพื่อให้เราสามารถกู้คืนระบบได้อย่างรวดเร็ว
• Monitoring and alerting: ตั้งค่า monitoring และ alerting เพื่อ detect ปัญหาที่เกิดขึ้นใน production และแจ้งเตือนให้เราทราบทันที

นอกจากนี้ การ debug workflow ใน GitHub Actions ก็อาจเป็นเรื่องท้าทาย ลองใช้ actions/cache เพื่อ cache dependencies และลดเวลาในการ build หรือใช้ tmate action เพื่อ SSH เข้าไปยัง workflow runner และ debug ปัญหาแบบ interactive

ตัวอย่างจากประสบการณ์จริง 20 ปี

จากประสบการณ์ 20 ปีในวงการ IT ผมได้เห็นการเปลี่ยนแปลงของ CI/CD มามากมาย สมัยก่อนการ deploy code ขึ้น production เป็นเรื่องที่น่ากลัวมาก ต้องทำตอนกลางคืน ต้องมีทีม standby คอยแก้ปัญหา แต่ด้วย CI/CD ทำให้กระบวนการนี้เป็นไปอย่างราบรื่นและปลอดภัยมากขึ้น

ผมเคยเซ็ต CI/CD pipeline ให้กับ startup แห่งหนึ่ง ตอนนั้นเราใช้ Jenkins เป็นหลัก แต่พอ GitHub Actions เริ่มเป็นที่นิยม เราก็ค่อยๆ migrate ไปใช้ GitHub Actions แทน เพราะมันง่ายกว่าเยอะ และ integrate กับ GitHub ได้ดีกว่า ทำให้ทีม developer ทำงานได้เร็วขึ้นมาก

อีกครั้งหนึ่ง ผมเคยเจอ project ที่มี code base ขนาดใหญ่มาก การ build แต่ละครั้งใช้เวลานานมาก ทำให้ CI/CD pipeline ช้า เราแก้ปัญหานี้โดยการใช้ Docker container และ caching dependencies ทำให้เวลาในการ build ลดลงอย่างมาก นอกจากนี้ เรายังใช้ Matrix Builds เพื่อทดสอบ code กับหลาย environments พร้อมกัน ทำให้เรามั่นใจได้ว่า code ของเราทำงานได้ดีในทุกสภาพแวดล้อม

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

เครื่องมือแนะนำสำหรับ CI/CD Pipeline

Jenkins: พระเอกตลอดกาล

GitLab CI: ครบจบในที่เดียว

CircleCI: ความง่ายที่มาพร้อมประสิทธิภาพ

เพิ่มเติม: Azure DevOps, AWS CodePipeline

Case Study: ประสบการณ์จริงกับ CI/CD Pipeline

FAQ: คำถามที่พบบ่อยเกี่ยวกับ CI/CD และ GitHub Actions

GitHub Actions ฟรีจริงหรือ? มีข้อจำกัดอะไรบ้าง?

ผมควรเริ่มต้นเรียนรู้ CI/CD และ GitHub Actions อย่างไรดี?

GitHub Actions เหมาะกับโปรเจกต์ขนาดเล็กเท่านั้นหรือไม่?

มีเครื่องมืออะไรบ้างที่สามารถใช้ร่วมกับ GitHub Actions ได้?

จะมั่นใจได้อย่างไรว่า CI/CD pipeline ของเราปลอดภัย?

ถ้า workflow ใน GitHub Actions fail จะเกิดอะไรขึ้น?

สรุป: CI/CD และ GitHub Actions คือเพื่อนซี้ที่จะยกระดับชีวิตคุณ

Tips จากประสบการณ์ 20 ปีในการทำ CI/CD Pipeline

1. เริ่มจากเล็กๆ อย่าใจร้อน

2. Test ให้ครอบคลุมที่สุดเท่าที่จะทำได้

3. Infrastructure as Code (IaC) สำคัญมาก

4. Monitor ทุกอย่าง

5. Security ต้องมาเป็นอันดับแรก

6. Documentation สำคัญเสมอ

7. Version Control คือเพื่อนแท้

8. อย่ากลัวที่จะลองผิดลองถูก

FAQ เกี่ยวกับ CI/CD Pipeline และ GitHub Actions

GitHub Actions ฟรีจริงหรือ? มีข้อจำกัดอะไรบ้าง?

Self-hosted runner คืออะไร? เหมาะกับใคร?

Docker จำเป็นไหมสำหรับการทำ CI/CD?

จะเริ่มต้นเรียนรู้ GitHub Actions อย่างไรดี?

ตารางเปรียบเทียบ CI/CD Tools ยอดนิยม