GitLab CI: ไพพ์ไลน์และการผสานรวมอย่างต่อเนื่อง

GitLab CI คืออะไร?

GitLab CI เป็นส่วนหนึ่งของแอปพลิเคชัน DevSecOps แบบครบวงจรของ GitLab ซึ่งครอบคลุมการผสานรวมอย่างต่อเนื่อง การส่งมอบ และการปรับใช้ ระบบเริ่มต้นเป็นโปรเจกต์แยกต่างหากในปี 2012 แต่ต่อมาถูกรวมเข้ากับ GitLab โดยตรง หลักการสำคัญคือการกำหนดค่าเป็นโค้ด (Configuration as Code) ผ่านไฟล์ .gitlab-ci.yml ในรูทของรีポジโทรี GitLab CI พร้อมใช้งานทั้งในเวอร์ชันคลาวด์ SaaS และการติดตั้งแบบจัดการเอง

สำหรับการพัฒนาโมบายล์ GitLab CI นำเสนอระบบอัตโนมัติสำหรับการบิลด์ APK และ IPA การรันการทดสอบแบบมีเครื่องมือ วิเคราะห์โค้ดแบบสแตติก การเซ็นแอป และการเผยแพร่สู่ร้านค้า แพลตฟอร์มรองรับ อิมเมจ Docker สำหรับสภาพแวดล้อมที่กำหนดเอง ซึ่งช่วยให้ติดตั้ง Android SDK, NDK, Xcode และเครื่องมืออื่น ๆ ล่วงหน้าได้ Container Registry ในตัวช่วยลดความซับซ้อนในการจัดเก็บและกระจายอิมเมจภายในทีม

สถาปัตยกรรม GitLab CI: Runners, Pipelines และ Stages

สถาปัตยกรรม GitLab CI ประกอบด้วยสามองค์ประกอบหลัก GitLab Runner คือเอเจนต์ที่ดำเนินการ jobs รันเนอร์สามารถเป็นแบบแชร์ (ให้โดย GitLab), กลุ่ม (สำหรับกลุ่มโปรเจกต์) หรือเฉพาะ (สำหรับโปรเจกต์เดียว) แต่ละรันเนอร์ลงทะเบียนด้วย executor: Shell, Docker, Kubernetes หรือ VirtualBox GitLab Runner รองรับการปรับขนาดอัตโนมัติเพื่อจัดการกับโหลดสูงสุด

ไพพ์ไลน์คือชุดของสเตจที่ทำงานตามลำดับ ภายในสเตจเดียว jobs จะทำงานแบบขนาน โครงสร้างทั่วไป สำหรับโปรเจกต์โมบายล์คือ: build → test → deploy หาก job ในสเตจ test ล้มเหลว deploy จะไม่ถูกเรียกใช้ สามารถกำหนดค่าการเรียกใช้ด้วยตนเอง (when: manual) สำหรับการปรับใช้ นอกจากนี้ยังรองรับทริกเกอร์ไพพ์ไลน์หลายโปรเจกต์สำหรับสถานการณ์ CI/CD ที่ซับซ้อนระหว่างรีポจโทรี

Executors ของ GitLab Runner

Docker executor เป็นที่นิยมที่สุดสำหรับ CI/CD ของแอปโมบายล์ แต่ละ job ทำงานในคอนเทนเนอร์ Docker ที่สะอาด ซึ่งรับประกันการแยกส่วนและความสามารถในการทำซ้ำ สำหรับการบิลด์ Android ใช้อิมเมจ android-sdk ที่ติดตั้ง SDK ล่วงหน้า สำหรับ iOS ใช้รันเนอร์ macOS กับ Shell executor

การกำหนดค่า .gitlab-ci.yml สำหรับโปรเจกต์โมบายล์

ไฟล์ .gitlab-ci.yml กำหนดไพพ์ไลน์ในรูปแบบ YAML ส่วนหลัก ได้แก่: image (อิมเมจ Docker), stages (รายการสเตจ), variables (ตัวแปรสภาพแวดล้อม), before_script (คำสั่งก่อนแต่ละ job) และ jobs พร้อมส่วน script, artifacts, cache GitLab CI รองรับ include — การรวมไฟล์ YAML ภายนอกเพื่อนำการกำหนดค่าร่วมกันระหว่างโปรเจกต์มาใช้ซ้ำ

ตัวแปรใน GitLab CI สามารถกำหนดได้หลายระดับ: ทั่วโลกใน UI, ในไฟล์กำหนดค่า, ในการตั้งค่ากลุ่มและโปรเจกต์ ลำดับความสำคัญของตัวแปร เป็นไปตามลำดับชั้น: ตัวแปรทริกเกอร์มีลำดับความสำคัญสูงสุด ตามด้วยตัวแปร CI/CD จาก UI จากนั้นจาก .gitlab-ci.yml ตัวแปรสามารถถูกป้องกัน ทำให้สามารถเข้าถึงได้เฉพาะจากสาขาและแท็กที่ถูกป้องกัน

ตัวแปรพื้นฐานและอิมเมจ

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job บิลด์พร้อมอาร์ติแฟกต์

Job generate-apk สร้างโปรเจกต์ Gradle และบันทึก APK เป็นอาร์ติแฟกต์ อาร์ติแฟกต์ จะถูกส่งต่อระหว่างสเตจ — job deploy สามารถใช้ APK จากสเตจ build ได้ การเก็บรักษาอาร์ติแฟกต์ถูกกำหนดค่าผ่าน expire_in

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI กับ GitHub Actions: ความแตกต่างหลัก

เมื่อเลือกระหว่าง GitLab CI และ GitHub Actions สำหรับโปรเจกต์โมบายล์ โครงสร้างพื้นฐานของทีมเป็นปัจจัยสำคัญ GitLab CI มี Container Registry ในตัวสำหรับจัดเก็บอิมเมจ Docker พร้อม Android SDK GitHub Actions ขึ้นอยู่กับ GitHub Packages หรือรีจิสทรีภายนอก GitLab ยังมี SAST (Static Application Security Testing) ในตัวสำหรับวิเคราะห์ช่องโหว่ของโค้ด

GitLab CI นำเสนอโมเดลรันเนอร์ที่ยืดหยุ่นกว่า — รองรับ Kubernetes executor, การปรับขนาดอัตโนมัติ และอิมเมจที่กำหนดเอง GitHub Actions โดดเด่นในการรวมกับระบบนิเวศ GitHub และตลาดการกระทำ GitLab CI ต้องการการกำหนดค่าด้วยตนเองมากขึ้นสำหรับงานหลายอย่างที่ GitHub Actions แก้ไขด้วยการกระทำสำเร็จรูป

จากมุมมองของ CI/CD โมบายล์: GitLab CI เหมาะกับบริษัทที่ใช้ GitLab Self-Managed อยู่แล้วและต้องการรันเนอร์โฮสต์เองกับ Docker/Kubernetes GitHub Actions สะดวกกว่าสำหรับทีมขนาดเล็กบนคลาวด์ GitHub ที่ให้ความสำคัญกับการกระทำสำเร็จรูปและความง่ายในการตั้งค่า

การเปรียบเทียบคุณสมบัติ

ตัวอย่างไพพ์ไลน์สำหรับโปรเจกต์ Android

ไพพ์ไลน์ Android ที่สมบูรณ์ประกอบด้วย: lint, การทดสอบหน่วย, การบิลด์ และการปรับใช้กับ Firebase App Distribution ไพพ์ไลน์ใช้ อิมเมจ Docker พร้อม Android SDK, การแคช Gradle และการทำงานแบบขนานของ lint และ test ในสเตจเดียวกัน แนวทางนี้ลดเวลาไพพ์ไลน์โดยรวมเนื่องจากงาน lint และ test เป็นอิสระต่อกัน

สำหรับโปรเจกต์ iOS โครงสร้างไพพ์ไลน์แตกต่างกันเนื่องจากต้องใช้รันเนอร์ macOS และการเซ็นโค้ด ไพพ์ไลน์ iOS ทั่วไป ประกอบด้วย: การติดตั้ง CocoaPods หรือ SPM, การรันทดสอบบนซิวมูเลเตอร์, การเก็บถาวรโปรเจกต์ Xcode, การส่งออก IPA และการอัปโหลดไปยัง TestFlight GitLab CI สำหรับ iOS ใช้รันเนอร์ macOS — ไม่ว่าจะเป็นรันเนอร์ SaaS GitLab macOS ที่มีข้อจำกัดด้านเวลาหรือรันเนอร์โฮสต์เองบน Mac Mini หรือ MacStadium

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

การปรับแต่งเวลาบิลด์ใน GitLab CI

การปรับแต่งไพพ์ไลน์การบิลด์โมบายล์ใน GitLab CI ต้องการความใส่ใจในรายละเอียด การกำหนดค่า cache และ artifacts ที่เหมาะสม สามารถลดเวลาบิลด์ได้หลายเท่า สำหรับการวิเคราะห์ประสิทธิภาพ GitLab มี CI/CD Analytics — แดชบอร์ดที่มีเมตริกระยะเวลาไพพ์ไลน์ โหลดรันเนอร์ และคอขวด วิเคราะห์เมตริกเหล่านี้เป็นประจำเพื่อค้นหาโอกาสในการปรับแต่ง การกำหนดค่า resource_group จะบล็อกการรันไพพ์ไลน์แบบขนาน — มีประโยชน์ในการป้องกันความขัดแย้งในการปรับใช้

กลยุทธ์สาขาสำหรับ CI ก็สำคัญเช่นกัน แนะนำให้รัน ไพพ์ไลน์เต็มเฉพาะสาขา main และ release และสำหรับสาขาฟีเจอร์ — เฉพาะ lint และการทดสอบหน่วยเท่านั้น ซึ่งประหยัดนาทีของรันเนอร์และเร่งการตอบกลับนักพัฒนา GitLab CI รองรับ workflow:rules — กฎแบบมีเงื่อนไขสำหรับการรวมหรือยกเว้น jobs ตามสาขา ไฟล์ที่เปลี่ยนแปลง หรือตัวแปรสภาพแวดล้อม

การแคช dependencies เป็นวิธีการเร่งความเร็วหลัก GitLab CI แคช .gradle, Pods และ node_modules ระหว่างการรัน คีย์แคชรวม $CI_COMMIT_REF_SLUG หรือแฮชของไฟล์ล็อก เวลาบิลด์โปรเจกต์ Android ลดลงจาก 10–15 เหลือ 2–4 นาทีด้วยการแคชที่เหมาะสม แคชสามารถกระจายได้ — GitLab รองรับ cache:key พร้อมการถอยกลับไปยังคีย์ก่อนหน้า

อิมเมจ Docker ที่มีเครื่องมือติดตั้งล่วงหน้าช่วยประหยัดเวลาติดตั้ง แนะนำให้ สร้างอิมเมจที่กำหนดเองด้วย Android SDK, NDK และระดับ API ที่ต้องการ การทำงาน jobs (lint, test, assemble) แบบขนานในสเตจต่าง ๆ ช่วยลดเวลาไพพ์ไลน์โดยรวม นโยบายดึงอิมเมจ (if-not-present) เร่งการเริ่มต้น jobs นอกจากนี้ยังสามารถใช้พร็อกซี dependencies เพื่อแคชอิมเมจในระดับอินสแตนซ์ GitLab

อีกแง่มุมสำคัญของการปรับแต่งคือการใช้อาร์ติแฟกต์ระหว่างสเตจ ไฟล์ขนาดใหญ่ เช่น APK และ IPA ควรส่งผ่าน dependency แทนที่จะสร้างใหม่ในแต่ละ job สำหรับโปรเจกต์ใหญ่ที่มีหลายสิบโมดูล แนะนำให้เปิดใช้งาน Gradle Build Cache ในระดับไพพ์ไลน์และกำหนดค่าแคชระยะไกลบนพื้นที่จัดเก็บร่วมกัน ควรตั้งค่าระยะหมดเวลาสำหรับแต่ละ job ตามเวลาบิลด์ที่คาดไว้ — ซึ่งป้องกันกระบวนการค้าง

ตัวอย่างพร้อมการแคชและนโยบายดึง

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present