การใช้ CI/CD Pipeline สำหรับ API

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

CI/CD คืออะไร?

CI/CD ย่อมาจาก Continuous Integration และ Continuous Delivery/Continuous Deployment เป็นแนวทางการพัฒนาซอฟต์แวร์ที่มุ่งเน้นการทำให้กระบวนการพัฒนาซอฟต์แวร์เป็นไปอย่างต่อเนื่องและอัตโนมัติ

Continuous Integration (CI): คือการรวมโค้ดจากนักพัฒนาหลายคนเข้าด้วยกันอย่างสม่ำเสมอ (เช่น ทุกครั้งที่มีการ push โค้ดขึ้น repository) จากนั้นจะทำการทดสอบโค้ดโดยอัตโนมัติ เพื่อให้แน่ใจว่าโค้ดที่รวมกันนั้นทำงานได้อย่างถูกต้องและไม่มีข้อผิดพลาด
Continuous Delivery (CD): คือการเตรียมพร้อมที่จะนำซอฟต์แวร์ไปใช้งานจริงได้ตลอดเวลา หลังจากผ่านกระบวนการ CI แล้ว CD จะทำการสร้าง package ที่สามารถนำไปติดตั้งบน environment ต่างๆ ได้อย่างง่ายดาย
Continuous Deployment (CD): คือการนำซอฟต์แวร์ไปใช้งานจริงโดยอัตโนมัติหลังจากผ่านกระบวนการ CI และ CD แล้ว

ทำไมต้องใช้ CI/CD?

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

การตั้งค่า CI/CD Pipeline

การตั้งค่า CI/CD Pipeline อาจแตกต่างกันไปขึ้นอยู่กับเครื่องมือและแพลตฟอร์มที่เราใช้ แต่โดยทั่วไปแล้วจะมีขั้นตอนหลักๆ ดังนี้:

เลือกเครื่องมือ CI/CD: มีเครื่องมือ CI/CD ให้เลือกมากมาย เช่น Jenkins, GitLab CI, GitHub Actions, CircleCI, Travis CI แต่ละเครื่องมือมีข้อดีข้อเสียแตกต่างกันไป ควรเลือกเครื่องมือที่เหมาะสมกับความต้องการและงบประมาณของเรา
กำหนด Workflow: กำหนดขั้นตอนการทำงานของ Pipeline เช่น การดึงโค้ด, การติดตั้ง dependencies, การทดสอบ, การสร้าง package, การนำไปใช้งาน
กำหนด Triggers: กำหนดเงื่อนไขที่จะทำให้ Pipeline เริ่มทำงาน เช่น การ push โค้ดขึ้น repository, การสร้าง pull request, การกำหนดเวลา
กำหนด Environment: กำหนด environment ที่จะใช้ในการทดสอบและนำ API ไปใช้งาน เช่น development, staging, production
เขียน Scripts: เขียน scripts ที่จะใช้ในการทำงานต่างๆ ใน Pipeline เช่น scripts สำหรับการติดตั้ง dependencies, การทดสอบ, การสร้าง package, การนำไปใช้งาน

ตัวอย่างการใช้ GitHub Actions สำหรับ CI/CD

GitHub Actions เป็นเครื่องมือ CI/CD ที่รวมอยู่ใน GitHub โดยตรง ทำให้ง่ายต่อการใช้งานสำหรับโปรเจ็กต์ที่ใช้ GitHub เป็น repository

ในการใช้งาน GitHub Actions เราจะต้องสร้างไฟล์ YAML ที่อยู่ใน directory .github/workflows ใน repository ของเรา ไฟล์ YAML นี้จะกำหนด Workflow ของ Pipeline

ตัวอย่างไฟล์ .github/workflows/ci.yml:

name: CI

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

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: '7.4' # หรือเวอร์ชันที่ต้องการ
    - name: Install Dependencies
      run: composer install --no-interaction --prefer-dist --optimize-autoloader
    - name: Run Tests
      run: ./vendor/bin/phpunit

คำอธิบาย:

name: CI: กำหนดชื่อของ Workflow
on:: กำหนด triggers ที่จะทำให้ Workflow เริ่มทำงาน ในที่นี้คือเมื่อมีการ push โค้ดขึ้น branch main หรือมีการสร้าง pull request ไปยัง branch main
jobs:: กำหนด jobs ที่จะทำงานใน Workflow ในที่นี้มี job เดียวคือ build
runs-on: ubuntu-latest: กำหนด operating system ที่จะใช้ในการทำงาน
steps:: กำหนดขั้นตอนการทำงานใน job build
actions/checkout@v2: ใช้ action สำหรับ checkout โค้ดจาก repository
shivammathur/setup-php@v2: ใช้ action สำหรับติดตั้ง PHP
composer install: ติดตั้ง dependencies โดยใช้ Composer
./vendor/bin/phpunit: รัน Unit Tests โดยใช้ PHPUnit

เมื่อเรา push โค้ดขึ้น repository หรือสร้าง pull request GitHub Actions จะเริ่มทำงานโดยอัตโนมัติตาม Workflow ที่เรากำหนดไว้ หากการทดสอบสำเร็จ Workflow จะถือว่าผ่าน หากการทดสอบล้มเหลว Workflow จะถือว่าไม่ผ่าน และเราจะได้รับการแจ้งเตือน

ตัวอย่างการเพิ่มขั้นตอนการ Deploy

สมมติว่าเราต้องการ Deploy API ของเราไปยัง server หลังจากผ่านการทดสอบแล้ว เราสามารถเพิ่มขั้นตอนการ Deploy เข้าไปใน Workflow ของเราได้

ตัวอย่างไฟล์ .github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/your-api
            git pull origin main
            composer install --no-interaction --prefer-dist --optimize-autoloader
            # เพิ่มคำสั่งอื่นๆ ที่จำเป็นสำหรับการ Deploy

คำอธิบาย:

appleboy/ssh-action@master: ใช้ action สำหรับเชื่อมต่อกับ server ผ่าน SSH
secrets.SSH_HOST, secrets.SSH_USERNAME, secrets.SSH_PRIVATE_KEY: ใช้ secrets ใน GitHub สำหรับเก็บข้อมูล sensitive เช่น host, username, และ private key ของ server
script:: กำหนด script ที่จะรันบน server
git pull origin main: ดึงโค้ดล่าสุดจาก repository
composer install: ติดตั้ง dependencies

ข้อควรระวัง:

ควรเก็บข้อมูล sensitive เช่น passwords, API keys, และ private keys ไว้ใน secrets เพื่อป้องกันไม่ให้ถูกเปิดเผย
ควรทดสอบ Pipeline อย่างละเอียดก่อนที่จะนำไปใช้งานจริง

ประโยชน์ของการใช้ CI/CD Pipeline

การใช้ CI/CD Pipeline มีประโยชน์มากมายดังนี้:

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

สรุป

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