CI/CD Pipeline — คืออะไร ขั้นตอนอัตโนมัติและเครื่องมือ

CI/CD Pipeline คืออะไร

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

ประวัติของ CI/CD

แนวคิดของ Continuous Integration ถูกอธิบายโดย Grady Booch ในปี 1991 และทำให้เป็นที่นิยมโดย Martin Fowler ในช่วงปี 2000 Continuous Delivery ในฐานะคำศัพท์ถูกกำหนดขึ้นหลังจากหนังสือ “Continuous Delivery” โดย Jez Humble และ David Farley (2010) CI/CD Pipeline สมัยใหม่กลายเป็นมาตรฐานโดยพฤตินัยในการพัฒนามือถือหลังจากปี 2015 — ด้วยการเกิดขึ้นของเซิร์ฟเวอร์ CI บนคลาวด์และระบบอัตโนมัติของร้านค้าแอป

ทำไมต้องใช้ CI/CD Pipeline ในการพัฒนามือถือ

แอปพลิเคชันมือถือมีข้อกำหนดเฉพาะสำหรับการ build และการเผยแพร่: การลงนามใบรับรอง การตั้งค่าหลายแบบ (debug, release, staging) การทำให้โค้ดสับสนด้วย ProGuard/R8 ประเภท build หลายแบบ (APK, AAB, IPA) และการรวมกับร้านค้าแอป การดำเนินการด้วยตนเองในขั้นตอนเหล่านี้ใช้เวลาหลายชั่วโมงและมีโอกาสผิดพลาดสูง — CI/CD Pipeline ทำให้งานประจำเป็นอัตโนมัติ

ขั้นตอน CI/CD Pipeline สำหรับแอปมือถือ

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

1. Checkout และการติดตั้ง dependencies

ไปป์ไลน์เริ่มต้นด้วยการโคลนพื้นที่เก็บข้อมูลและติดตั้ง dependencies: Gradle/Maven สำหรับ Android, CocoaPods หรือ SPM สำหรับ iOS การแคช dependencies ระหว่างการเรียกใช้ช่วยลดเวลาการติดตั้งจาก 3–5 นาทีเหลือเพียงไม่กี่วินาที — บริการ CI สมัยใหม่ทั้งหมดรองรับการปรับแต่งนี้

2. การวิเคราะห์แบบสแตติกและการ linting

ก่อนการ build โค้ดจะถูกตรวจสอบโดย linter (ktlint, detekt สำหรับ Android, SwiftLint สำหรับ iOS) และเครื่องมือวิเคราะห์แบบสแตติก (Android Lint, SonarQube) การ linting ตรวจหาบั๊กที่อาจเกิดขึ้น การละเมิดรูปแบบโค้ด และ API ที่เลิกใช้แล้วก่อนเรียกใช้การทดสอบ — หลักการ fail-fast ช่วยประหยัดเวลาของทีม

3. การ build โปรเจกต์

ในขั้นตอนการ build โปรเจกต์ทั้งหมดจะถูกคอมไพล์และสร้างสิ่งประดิษฐ์: APK และ AAB สำหรับ Android, IPA สำหรับ iOS สำหรับ Android ใช้งาน Gradle tasks (assembleDebug, bundleRelease) สำหรับ iOS — xcodebuild หรือ xcrun การ build ดำเนินการในสภาพแวดล้อมที่แยกจากกันของเซิร์ฟเวอร์ CI ซึ่งรับประกันความสามารถในการทำซ้ำ

# ตัวอย่าง CI/CD Pipeline สำหรับ Android บน GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. การทดสอบอัตโนมัติ

หลังจากการ build จะมีการเรียกใช้การทดสอบหน่วย การทดสอบการรวม และการทดสอบ UI JUnit และ MockK สำหรับการทดสอบหน่วย, Espresso และ Compose Test สำหรับ UI บน Android, XCTest และ XCUITest บน iOS ผลลัพธ์ถูกเผยแพร่ในรายงานและบล็อกไปป์ไลน์หากการทดสอบที่สำคัญล้มเหลว

5. การลงนามและการทำให้โค้ดสับสน

สำหรับ build ที่เผยแพร่ จะมีการลงนามด้วยใบรับรองดิจิทัล (APK Signer สำหรับ Android, codesign สำหรับ iOS) และการทำให้โค้ดสับสน ProGuard หรือ R8 สำหรับ Android ลดขนาด APK ลง 15–30% คีย์ลงนามถูกเก็บไว้ในความลับของเซิร์ฟเวอร์ CI — ไม่เคย commit ลงในพื้นที่เก็บข้อมูล

6. การส่งมอบและการปรับใช้

ขั้นตอนสุดท้ายของไปป์ไลน์คือการเผยแพร่สิ่งประดิษฐ์: อัปโหลด APK ไปยังการทดสอบภายในของ Google Play Console ส่ง IPA ไปยัง TestFlight หรือเผยแพร่ใน Firebase Distribution Continuous Delivery หมายถึงขั้นตอนนี้ต้องการการอนุมัติด้วยตนเอง ในขณะที่ Continuous Deployment จะทำงานอัตโนมัติ

7. การแจ้งเตือนและรายงาน

หลังจากไปป์ไลน์เสร็จสมบูรณ์ ทีมจะได้รับการแจ้งเตือนพร้อมผลลัพธ์: สำเร็จ/ล้มเหลว เวลาดำเนินการ ลิงก์ไปยังสิ่งประดิษฐ์ Slack, Telegram หรืออีเมล — ช่องทางการแจ้งเตือนถูกเลือกตามความต้องการของทีม เมื่อขั้นตอนล้มเหลว การแจ้งเตือนจะมีลิงก์ไปยังบันทึกข้อผิดพลาดเฉพาะ

ความแตกต่างระหว่าง CI และ CD

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

Continuous Integration — การตรวจสอบคุณภาพ

CI ทำงานทุกครั้งที่มี push หรือ pull request และรวมถึงการ build การวิเคราะห์แบบสแตติกและการทดสอบ เป้าหมายของ CI คือการตรวจหาปัญหาโดยเร็วที่สุด เมื่อค่าใช้จ่ายในการแก้ไขน้อยที่สุด หาก CI ล้มเหลว — โค้ดจะไม่เข้าสู่สาขาหลัก เวลาดำเนินการ CI เฉลี่ยสำหรับโปรเจกต์มือถือคือ 5–15 นาที

Continuous Delivery — ความพร้อมในการเผยแพร่

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

เครื่องมือสำหรับสร้าง CI/CD Pipeline

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

GitHub Actions

CI/CD ในตัวของ GitHub มีขีดจำกัดฟรี 2000 นาทีต่อเดือนสำหรับพื้นที่เก็บข้อมูลสาธารณะ GitHub Actions ได้รับความนิยมด้วยระบบนิเวศขนาดใหญ่ของ actions สำเร็จรูป (ตลาด) การตั้งค่าง่ายผ่าน YAML และการรวมที่ไร้รอยต่อกับพื้นที่เก็บข้อมูล GitHub ข้อจำกัด — ไม่รองรับ Windows runner สำหรับ build iOS ในแผนฟรี

GitLab CI/CD

โซลูชันที่โฮสต์เองและบนคลาวด์พร้อมตัวกำหนดค่า YAML ที่ทรงพลัง GitLab CI รองรับงานแบบขนาน การแคช สิ่งประดิษฐ์ และสภาพแวดล้อม เป็นที่นิยมในกลุ่มองค์กรด้วยความสามารถในการปรับใช้บนโครงสร้างพื้นฐานของตนเองและการควบคุมข้อมูลอย่างสมบูรณ์

Jenkins

เซิร์ฟเวอร์ CI โอเพนซอร์สคลาสสิก Jenkins ถูกกำหนดค่าผ่านปลั๊กอิน (มากกว่า 1800) รองรับ Declarative Pipeline ในรูปแบบ Groovy และทำงานในทุกสภาพแวดล้อม: Windows, macOS, Linux ต้องการการบริหารจัดการโดยเฉพาะแต่ให้ความยืดหยุ่นในการกำหนดค่าสูงสุด

CircleCI

บริการ CI บนคลาวด์ที่เน้นความเร็วและความเรียบง่าย CircleCI แคช dependencies โดยอัตโนมัติ รองรับอิมเมจ Docker สำหรับ build ที่แยกจากกัน และรวมกับ macOS สำหรับ build iOS การกำหนดราคาขึ้นอยู่กับเครดิต — เหมาะสำหรับทีมที่ให้ความสำคัญกับประสิทธิภาพ

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

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

# Fastfile — การกำหนดค่า Fastlane สำหรับ iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "รันการทดสอบและลินต์"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "สร้างรีลีสและอัปโหลดไปยัง TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match จัดการใบรับรองและโปรไฟล์การจัดเตรียม build_app สร้าง IPA pilot อัปโหลด build ไปยัง TestFlight คำสั่ง fastlane release ดำเนินการทุกขั้นตอนตามลำดับ: ดึงใบรับรอง สร้าง ลงนาม อัปโหลดไปยัง App Store Connect สำหรับผู้ทดสอบเบต้า

CI/CD Pipeline สำหรับ iOS ด้วย GitHub Actions

การรวม Fastlane กับ GitHub Actions ช่วยให้เรียกใช้ไปป์ไลน์ทั้งหมดโดยอัตโนมัติเมื่อมี pull request ไปยังสาขาหลัก จำเป็นต้องมี runner ที่โฮสต์เอง บน macOS สำหรับการคอมไพล์โค้ด iOS — GitHub ไม่มี macOS runner ในแผนฟรี

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

แนวทางปฏิบัติที่ดีที่สุดสำหรับ CI/CD Pipeline

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

Fail Fast (ล้มเหลวเร็ว)

การตรวจสอบที่เร็วที่สุด (linting, การทดสอบหน่วย) จะทำงานก่อน หากล้มเหลว — ไปป์ไลน์จะสิ้นสุดโดยไม่เรียกใช้การทดสอบ UI ที่ยาวหรือ build ที่เผยแพร่ Fail fast ช่วยประหยัดเวลา CI ได้นาทีและเร่งการตอบกลับให้นักพัฒนา เวลาเฉลี่ยจนถึงความล้มเหลวครั้งแรกไม่ควรเกิน 2–3 นาที

การแคช dependencies

แคช Gradle, แคช CocoaPods และแคช SPM ควรถูกกู้คืนระหว่างการเรียกใช้ GitHub Actions รองรับการแคชผ่าน actions/cache, GitLab CI ผ่านคีย์เวิร์ด cache หากไม่มีการแคช แต่ละ build จะดาวน์โหลด dependencies ทั้งหมดใหม่ — เพิ่มเวลา 3–10 นาทีให้กับไปป์ไลน์

การทำงานแบบขนาน

ขั้นตอนอิสระ (linter สำหรับ Android และ iOS, การทดสอบหน่วยของโมดูลต่างๆ) จะทำงานเป็นงานแบบขนาน การทำขนาน ลดเวลารวมของไปป์ไลน์จาก 20–30 นาทีเหลือ 5–10 นาที บริการ CI ส่วนใหญ่คิดค่างานแบบขนานแยกต่างหาก — โปรดจำไว้เมื่อเลือกแผน

การแยกสภาพแวดล้อม

การเรียกใช้ไปป์ไลน์แต่ละครั้งดำเนินการในสภาพแวดล้อมที่สะอาด: คอนเทนเนอร์ Docker, เครื่องเสมือน หรือ runner ชั่วคราว การแยก ป้องกันไม่ให้ build ก่อนหน้ามีผลต่อ build ปัจจุบัน หลีกเลี่ยงการใช้ runner ร่วมกันระหว่างโปรเจกต์ — การปนเปื้อนสภาพแวดล้อมข้ามโปรเจกต์นำไปสู่ความล้มเหลวที่ไม่สามารถกำหนดได้

ความปลอดภัยของความลับ

คีย์ API ใบรับรองการลงนาม และโทเค็นการเข้าถึงร้านค้าแอปถูกเก็บไว้ในที่เก็บที่เข้ารหัสของเซิร์ฟเวอร์ CI อย่ารวมความลับในบันทึก สิ่งประดิษฐ์ หรือตัวแปรสภาพแวดล้อมโดยไม่มีคำนำหน้า SECRET_ ใช้เครื่องมือเช่น Fastlane match สำหรับการจัดการใบรับรอง iOS