Continuous Integration (CI) — คืออะไร หลักการ และการตั้งค่าระบบอัตโนมัติ

Continuous Integration คืออะไร

Continuous Integration (CI) คือวิธีการพัฒนาที่ทำให้กระบวนการรวมโค้ดจากผู้มีส่วนร่วมหลายคนเป็นฐานโค้ดเดียวเป็นไปโดยอัตโนมัติ คำนี้ถูกนำเสนอโดย Martin Fowler ในช่วงต้นทศวรรษ 2000 เพื่อเป็นชุดแนวปฏิบัติในการป้องกัน “nรกแห่งการรวมระบบ” — สถานการณ์ที่นักพัฒนาทำงานแยกกันเป็นเวลาหลายสัปดาห์ และเมื่อรวมการเปลี่ยนแปลง เกิดข้อขัดแย้งมากมายที่ต้องใช้เวลาหลายวันในการแก้ไขด้วยตนเอง

ปัญหาที่ CI แก้ไข

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

ผลกระทบทางเศรษฐกิจของ CI

ตามข้อมูลของ IBM Systems Sciences Institute ค่าใช้จ่ายในการแก้ไขบั๊กในขั้นตอนการเขียนโค้ดคือ $25 ในขั้นตอนการทดสอบคือ $100 และในขั้นตอนการผลิตคือ $2,500 CI เลื่อนการตรวจจับข้อบกพร่องไปทางซ้ายให้มากที่สุด (shift left) ค้นหาข้อผิดพลาดในขั้นตอนคอมมิตเมื่อการแก้ไขแทบไม่มีค่าใช้จ่าย ทีมที่ใช้ CI ใช้เวลาเฉลี่ย 15% ในการดีบัก เทียบกับ 35% สำหรับทีมที่ไม่มี CI

หลักการพื้นฐานของ Continuous Integration

Martin Fowler กำหนดแนวปฏิบัติหลักของ CI ที่ยังคงเกี่ยวข้องไม่ว่าจะใช้สแต็กเทคโนโลยีใดก็ตาม การปฏิบัติตามหลักการเหล่านี้ทำให้มั่นใจได้ว่า CI ให้คุณค่าแทนที่จะเป็นภาระทางราชการ การพัฒนาแอปมือถือเพิ่มข้อกำหนดเพิ่มเติม แต่แกนหลักยังคงไม่เปลี่ยนแปลง

พื้นที่เก็บข้อมูลเดียว

โค้ดทั้งหมดของโปรเจกต์ถูกเก็บในพื้นที่เก็บข้อมูลเดียวที่มีระบบควบคุมเวอร์ชันแบบรวม (Git) แหล่งความจริงเดียวช่วยขจัดสถานการณ์ที่ฟีเจอร์ถูกพัฒนาใน fork และไม่ซิงค์กับฐานโค้ดหลักเป็นเวลาหลายสัปดาห์ ในโปรเจกต์มือถือ หมายความว่าส่วน Android, iOS และ backend สามารถอยู่ในพื้นที่เก็บข้อมูลเดียว (monorepo) หรือในพื้นที่เก็บข้อมูลแยกกันด้วยแผนการกำหนดเวอร์ชันร่วมกัน

บิลด์อัตโนมัติ

บิลด์ของโปรเจกต์ต้องดำเนินการได้ด้วยคำสั่งเดียว สำหรับ Android คือ ./gradlew assembleDebug สำหรับ iOS — xcodebuild หรือ fastlane build สคริปต์บิลด์ตรวจสอบความสามารถในการทำซ้ำ: บิลด์บนเซิร์ฟเวอร์ CI ต้องให้ผลลัพธ์เดียวกันกับบนเครื่องของนักพัฒนา ความแตกต่างของสภาพแวดล้อมใด ๆ จะถูกขจัดโดยการทำคอนเทนเนอร์หรือ IaC (Infrastructure as Code)

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

หลังจากบิลด์ การทดสอบทุกระดับจะดำเนินการ: หน่วย การรวม และ UI หากการทดสอบล้มเหลว คอมมิตจะถือว่าไม่ถูกต้อง การรักษาสถานะสีเขียวเป็นความรับผิดชอบร่วมกันของทีม ในโปรเจกต์มือถือ การทดสอบเร็ว (ดำเนินการภายใน 5 นาทีต่อคอมมิต) มักแยกจากการทดสอบช้า (การทดสอบ UI บนอุปกรณ์จริง ดำเนินการน้อยครั้งกว่า)

// ตัวอย่างการทดสอบหน่วยพร้อมรายงานที่รองรับ CI
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast และความโปร่งใส

ผลลัพธ์ของ CI เปิดเผยต่อทั้งทีม: ทุกคนสามารถเห็นว่าคอมมิตของใครทำให้บิลด์เสียหาย ความโปร่งใสสร้างวัฒนธรรมความรับผิดชอบ: นักพัฒนาตรวจสอบการเปลี่ยนแปลงของตนก่อน push และแก้ไขบิลด์ที่เสียหายนอกคิว เซิร์ฟเวอร์ CI ส่งการแจ้งเตือนไปยัง Slack หรือ Telegram เมื่อสถานะบิลด์เปลี่ยนไป

ส่วนประกอบของระบบ CI

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

เซิร์ฟเวอร์ CI

ส่วนประกอบกลางที่จัดการคิวบิลด์ การจัดสรรทรัพยากร และการเผยแพร่ผลลัพธ์ เซิร์ฟเวอร์ CI สามารถเป็นแบบคลาวด์ (GitHub Actions, GitLab CI, CircleCI) หรือแบบโฮสต์เอง (Jenkins, TeamCity) เซิร์ฟเวอร์ติดตามการเปลี่ยนแปลงในพื้นที่เก็บข้อมูลผ่าน webhook หรือ polling และเรียกใช้ไปป์ไลน์ในทุก push หรือ pull request

รันเนอร์และเอเจนต์

รันเนอร์คือเครื่องเสมือนหรือเครื่องจริงที่ดำเนินงานบิลด์ ใน CI แบบคลาวด์ รันเนอร์ถูกจัดหาโดยผู้ให้บริการและคิดค่าบริการตามเวลาใช้งาน รันเนอร์แบบโฮสต์เองถูกติดตั้งบนโครงสร้างพื้นฐานของคุณเองและต้องมีการบำรุงรักษา บิลด์ iOS ต้องใช้รันเนอร์ macOS บิลด์ Android ต้องใช้ Linux หรือ Windows

อาร์ติแฟกต์และแคช

หลังจากบิลด์ ระบบ CI จะบันทึกอาร์ติแฟกต์ (APK, IPA, รายงานการทดสอบ) ในที่เก็บ — สามารถดาวน์โหลดและนำไปใช้งานได้ การแคช dependencies (แคช Gradle, แคช CocoaPods) ระหว่างการทำงานช่วยเร่งบิลด์ครั้งต่อไปได้ 3–5 เท่า

Continuous Integration สำหรับแอปพลิเคชันมือถือ

การพัฒนาแอปมือถือมีข้อกำหนดพิเศษสำหรับ CI ที่แตกต่างจากโปรเจกต์เว็บหรือ backend เวลาบิลด์ที่ยาวนาน (3–15 นาทีสำหรับ Android, 5–20 นาทีสำหรับ iOS) อาร์ติแฟกต์หลายประเภท (APK, AAB, IPA) ความจำเป็นในการลงนามและการทำให้สับสน — ทั้งหมดนี้ต้องมีการกำหนดค่าไปป์ไลน์ CI แบบกำหนดเอง

ไปป์ไลน์ CI สำหรับ Android

CI ทั่วไปสำหรับ Android รวมถึง: ลินติ้ง (ktlint, detekt) และการวิเคราะห์แบบสแตติก การทดสอบหน่วยด้วย JUnit และ MockK บิลด์ APK/AAB สำหรับ debug และ release การทดสอบเครื่องมือบนอีมูเลเตอร์ภายใน CI และ การเผยแพร่อาร์ติแฟกต์ แคช Gradle ช่วยเร่งบิลด์ซ้ำ — หากไม่มี แต่ละบิลด์จะดาวน์โหลด dependencies ใหม่ เสียเวลา 3–5 นาที

ไปป์ไลน์ CI สำหรับ iOS

CI สำหรับ iOS ต้องใช้ รันเนอร์ macOS เพื่อคอมไพล์โค้ด Swift/Objective-C ไปป์ไลน์รวมถึง: การติดตั้ง dependencies ของ CocoaPods หรือ SPM SwiftLint สำหรับตรวจสอบสไตล์ การทดสอบหน่วยด้วย XCTest บิลด์ IPA การลงนามโค้ดผ่าน Fastlane match และอัปโหลดไปยัง TestFlight รันเนอร์แบบโฮสต์เองบน Mac mini หรือ Mac ในศูนย์ข้อมูลเป็นทางเลือกแทนรันเนอร์ macOS แบบคลาวด์

โปรเจกต์ข้ามแพลตฟอร์ม (Flutter, React Native)

Flutter และ React Native คอมไพล์เป็นบิลด์เนทีฟสำหรับทั้งสองแพลตฟอร์ม CI ต้องรองรับ สองรันเนอร์: Linux สำหรับบิลด์ Android และ macOS สำหรับบิลด์ iOS กลยุทธ์ที่ดีที่สุดคือไปป์ไลน์แบบแยก: บิลด์ Android บนรันเนอร์ Linux บิลด์ iOS บนรันเนอร์ macOS หลังจากนั้นอาร์ติแฟกต์ทั้งสองจะรวมกันเป็นรุ่นเดียว

การเปรียบเทียบเครื่องมือ CI

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

GitHub Actions

ฟรีสำหรับพื้นที่เก็บข้อมูลสาธารณะ (2000 นาที/เดือน) GitHub Actions มีระบบนิเวศของการดำเนินการพร้อมใช้สำหรับ Android (gradle/actions) และ iOS (apple-actions) ข้อเสียคือรันเนอร์ macOS มีให้เฉพาะในแผนบริการแบบชำระเงิน เหมาะสำหรับโอเพนซอร์สและทีมขนาดเล็กที่ใช้ GitHub อยู่แล้ว

Jenkins

เซิร์ฟเวอร์ CI แบบโฮสต์เองและโอเพนซอร์ส Jenkins ถูกกำหนดค่าผ่าน Groovy Pipeline รองรับปลั๊กอินหลายร้อยตัวและทำงานบนฮาร์ดแวร์ใดก็ได้ ต้องมีวิศวกร DevOps สำหรับการติดตั้งและบำรุงรักษา เป็นที่นิยมในกลุ่มองค์กรที่การควบคุมโครงสร้างพื้นฐานเป็นสิ่งสำคัญ

GitLab CI

CI/CD ในตัวใน GitLab พร้อมสถาปัตยกรรมรันเนอร์แบบเปิด GitLab CI อนุญาตให้ใช้รันเนอร์ของคุณเอง (รวมถึง macOS) ในแผนฟรี การกำหนดค่า YAML มีประสิทธิภาพมากกว่า GitHub Actions แต่เรียนรู้ยากกว่า เหมาะสำหรับทีมที่ใช้ GitLab เป็นแพลตฟอร์ม DevOps เดียว

CircleCI

CI แบบคลาวด์ที่เน้นความเร็ว CircleCI รองรับอิมเมจ Docker, macOS และ Android และแคช dependencies โดยอัตโนมัติ การกำหนดราคาแบบเครดิต — แพงกว่า GitHub Actions สำหรับทีมขนาดเล็ก แต่เร็วกว่าเนื่องจากรันเนอร์ที่ปรับให้เหมาะสม แนะนำสำหรับโปรเจกต์การผลิตที่มีข้อกำหนดด้านความเร็ว

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

พิจารณาการตั้งค่า CI สำหรับโปรเจกต์ Android โดยใช้ GitHub Actions ไปป์ไลน์ดำเนินการวิเคราะห์แบบสแตติก บิลด์ และการทดสอบในทุก push และ pull request ไปยังสาขา main การกำหนดค่าขั้นต่ำใช้เวลา 15 นาทีและไม่ต้องใช้บริการภายนอก

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

ไปป์ไลน์ประกอบด้วยสองงานที่ทำงานพร้อมกัน: lint (ดำเนินการวิเคราะห์แบบสแตติก) และ unit-tests (ขึ้นอยู่กับ lint — หากลินติ้งล้มเหลว การทดสอบจะไม่ทำงาน) งาน unit-tests อัปโหลดรายงานการทดสอบเป็นอาร์ติแฟกต์ — ทีมสามารถตรวจสอบได้ในอินเทอร์เฟซ GitHub Actions โดยไม่ต้องดาวน์โหลดไฟล์ในเครื่อง

การตรวจสอบในเครื่องก่อน CI

เพื่อหลีกเลี่ยงความล้มเหลวของ CI จากข้อผิดพลาดเล็กน้อย ให้ตั้งค่า pre-push hook ใน Git หรืองาน Gradle ที่เรียกใช้การตรวจสอบเดียวกันในเครื่อง ตัวอย่าง: ./gradlew ktlintCheck detekt testDebugUnitTest หากการตรวจสอบในเครื่องใช้เวลามากกว่า 3 นาที ให้แยกเป็นการตรวจสอบเร็ว (ลินเตอร์) และช้า (การทดสอบ) โดยเรียกใช้การตรวจสอบเร็วก่อนทุกคอมมิตและการตรวจสอบช้าก่อน push เท่านั้น