CI/CD Pipeline — ano ito, mga yugto ng automation at mga tool

Ano ang CI/CD Pipeline

CI/CD Pipeline — ay isang pormal at automated na hanay ng mga proseso na pinagdadaanan ng code mula sa sandali ng pag-kommit ng mga pagbabago sa repository hanggang sa pag-deploy sa produksyon. Pinagsasama ng termino ang dalawang kasanayan: Continuous Integration (patuloy na integrasyon) at Continuous Delivery (patuloy na paghahatid), na magkasamang bumubuo ng pipeline ng paghahatid ng software.

Kasaysayan ng paglitaw ng CI/CD

Ang konsepto ng Continuous Integration ay inilarawan ni Grady Booch noong 1991 at pinasikat ni Martin Fowler noong 2000s. Ang Continuous Delivery bilang isang termino ay pinatibay pagkatapos ng aklat nina Jez Humble at David Farley na “Continuous Delivery” (2010). Ang modernong CI/CD Pipeline ay naging de facto standard sa pag-develop ng mobile app pagkatapos ng 2015 — sa pagdating ng cloud CI server at automation ng mga app store.

Bakit kailangan ang CI/CD Pipeline sa pag-develop ng mobile app

Ang mga mobile app ay may partikular na pangangailangan para sa pag-build at pag-publish: pag-sign gamit ang mga sertipiko, maraming configuration (debug, release, staging), ProGuard/R8 obfuscation, maraming uri ng build (APK, AAB, IPA) at integrasyon sa mga app store. Ang manu-manong pagsasagawa ng mga hakbang na ito ay tumatagal ng mga oras at madaling magkamali — ina-automate ng CI/CD Pipeline ang mga routine.

Mga yugto ng CI/CD Pipeline para sa mobile apps

Ang standard na CI/CD Pipeline para sa Android o iOS app ay binubuo ng pitong pangunahing yugto. Ang ilang yugto ay isinasagawa nang parallel, ang iba ay sunud-sunod. Ang eksaktong komposisyon ng mga yugto ay depende sa technology stack at kapanahunan ng team, ngunit ang core ay nananatiling hindi nagbabago.

1. Checkout at pag-install ng mga dependency

Nagsisimula ang pipeline sa pag-clone ng repository at pag-install ng mga dependency: Gradle/Maven para sa Android, CocoaPods o SPM para sa iOS. Pag-cache ng mga dependency sa pagitan ng mga run ay nagpapababa ng oras ng pag-install mula 3–5 minuto hanggang ilang segundo — ang optimization na ito ay sinusuportahan ng lahat ng modernong CI service.

2. Static analysis at linting

Bago ang pag-build, ang code ay sinusuri ng mga linter (ktlint, detekt para sa Android, SwiftLint para sa iOS) at static analyzer (Android Lint, SonarQube). Ang linting ay nakakatuklas ng potensyal na bug, paglabag sa code style at deprecated API bago patakbuhin ang mga test — ang fail-fast principle ay nakakatipid ng oras ng team.

3. Pag-build ng proyekto

Sa yugto ng pag-build, ang buong proyekto ay.compile at ang mga artifact ay ginagawa: APK at AAB para sa Android, IPA para sa iOS. Para sa Android ginagamit ang mga Gradle task (assembleDebug, bundleRelease), para sa iOS — xcodebuild o xcrun. Ang pag-build ay isinasagawa sa isolated na environment ng CI server, na ginagarantiyahan ang reproducibility.

# Halimbawa ng CI/CD Pipeline para sa Android sa 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. Automated testing

Pagkatapos ng pag-build, ang mga unit test, integration test at UI test ay pinapatakbo. JUnit at MockK para sa modular test, Espresso at Compose Test para sa UI sa Android, XCTest at XCUITest sa iOS. Ang mga resulta ay nai-publish sa ulat at hinaharangan ang pipeline kapag may kritikal na test na nabigo.

5. Pag-sign at obfuscation

Para sa release build, isinasagawa ang pag-sign gamit ang digital certificate (APK Signer para sa Android, codesign para sa iOS) at code obfuscation. ProGuard o R8 para sa Android ay nagpapaliit ng laki ng APK ng 15–30%. Ang mga signing key ay nakaimbak sa mga secret ng CI server — hindi kailanman ni-commit sa repository.

6. Paghahatid at pag-deploy

Ang huling yugto ng pipeline — pag-publish ng mga artifact: pag-upload ng APK sa internal testing ng Google Play Console, pagpapadala ng IPA sa TestFlight o pag-publish sa Firebase Distribution. Continuous Delivery ay nangangahulugan na ang hakbang na ito ay nangangailangan ng manu-manong kumpirmasyon, habang ang Continuous Deployment ay awtomatikong ginagawa.

7. Mga abiso at ulat

Pagkatapos ng pipeline, ang team ay makakatanggap ng abiso na may mga resulta: tagumpay/kabiguan, oras ng execution, link sa mga artifact. Slack, Telegram o email — mga channel ng abiso ay pinipili ayon sa pangangailangan ng team. Kapag nabigo ang yugto, ang link sa partikular na error log ay kasama sa abiso.

Ano ang pagkakaiba ng CI at CD

Ang mga terminong CI at CD ay madalas na ginagamit bilang isang konsepto na CI/CD, ngunit may pangunahing pagkakaiba sa pagitan nila. Ang CI (Continuous Integration) ay responsable para sa quality check sa bawat integrasyon ng code, habang ang CD (Continuous Delivery) ay tinitiyak ang kahandaan ng code na ito para sa release. Ang pag-unawa sa pagkakaiba ay mahalaga sa pag-disenyo ng pipeline.

Continuous Integration — quality check

Ang CI ay isinasagawa sa bawat push o pull request at kasama ang pag-build, static analysis at testing. Layunin ng CI — matukoy ang mga problema sa lalong madaling panahon, kung kailan minimal ang gastos ng pag-aayos. Kung hindi pumasa ang CI — hindi pumapasok ang code sa main branch. Ang average na oras ng execution ng CI para sa mobile project ay 5–15 minuto.

Continuous Delivery — kahandaan para sa release

Ang CD ay nagdaragdag sa CI ng mga yugto ng paghahanda ng release: pag-sign, obfuscation, paggawa ng release notes, pagsusuri ng lisensya, pag-publish sa storage para sa mga tester. Ginagarantiyahan ng CD na ang bawat commit sa main branch ay maaaring i-deploy sa produksyon sa isang click, ngunit ang release mismo ay nangangailangan ng manu-manong pag-apruba.

Mga tool para sa pagbuo ng CI/CD Pipeline

Ang ecosystem ng mga tool sa CI/CD para sa pag-develop ng mobile app ay may kasamang cloud service, self-hosted solution at specialized platform. Ang pagpili ng tool ay depende sa laki ng team, budget at mga kinakailangan sa seguridad. Sa ibaba ay ang pinakasikat na mga opsyon.

GitHub Actions

Built-in CI/CD sa GitHub na may libreng limit na 2000 minuto bawat buwan para sa pampublikong repository. GitHub Actions ay sikat dahil sa malaking ecosystem ng mga ready-made action (marketplace), kadalian ng configuration sa pamamagitan ng YAML at seamless na integrasyon sa GitHub repository. Limitasyon — walang suporta para sa Windows runner para sa iOS build sa libreng plano.

GitLab CI/CD

Self-hosted at cloud solution na may malakas na YAML configurator. GitLab CI ay sumusuporta sa parallel job, caching, artifact at environment (environments). Sikat sa enterprise segment dahil sa posibilidad ng pag-deploy sa sariling imprastraktura at ganap na kontrol sa data.

Jenkins

Classic CI server na may open source. Jenkins ay kino-configure sa pamamagitan ng mga plugin (higit sa 1800), sumusuporta sa Declarative Pipeline sa Groovy format at gumagana sa anumang environment: Windows, macOS, Linux. Nangangailangan ng dedicated administration, ngunit nagbibigay ng maximum na flexibility ng configuration.

CircleCI

Cloud CI service na may diin sa bilis at pagiging simple. CircleCI ay awtomatikong nag-ca-cache ng mga dependency, sumusuporta sa Docker image para sa isolated build at integrasyon sa macOS para sa iOS build. Ang pagpepresyo ay batay sa bilang ng credits — angkop para sa mga team na pinahahalagahan ang performance.

Halimbawa ng configuration ng CI/CD Pipeline

Tingnan natin ang isang kumpletong CI/CD Pipeline para sa iOS app gamit ang GitHub Actions at Fastlane. Ang Fastlane ay isang automation tool para sa mobile project na nag-aabstrak ng kumplikadong operasyon ng pag-build, pag-sign at pag-publish sa simpleng command.

# Fastfile — configuration ng Fastlane para sa iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Pagpapatakbo ng mga test at linting"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Pagbuo ng release at pag-upload sa 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 ay namamahala ng mga sertipiko at provisioning profile, build_app ay nagbu-build ng IPA, pilot ay nag-u-upload ng build sa TestFlight. Ang command na fastlane release ay nagsasagawa ng lahat ng yugto nang sunud-sunod: kumukuha ng mga sertipiko, nagbu-build, pumirma, nag-u-upload sa App Store Connect para sa beta tester.

CI/CD Pipeline para sa iOS gamit ang GitHub Actions

Ang integrasyon ng Fastlane sa GitHub Actions ay nagbibigay-daan sa awtomatikong pagpapatakbo ng buong pipeline sa pull request sa main branch. Self-hosted runner sa macOS ay kinakailangan para sa pag-compile ng iOS code — hindi nagbibigay ang GitHub ng macOS runner sa libreng plano.

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 }}

Pinakamahusay na kasanayan sa CI/CD Pipeline

Ang pagbuo ng epektibong CI/CD Pipeline ay hindi lamang nangangailangan ng pagpili ng mga tool, kundi pati na rin ng pagsunod sa mga napatunayang kasanayan. Kung walang tamang organisasyon, ang pipeline ay maaaring maging bottleneck na nagpapabagal sa pag-develop sa halip na pabilisin ito. Sa ibaba — mga pangunahing rekomendasyon batay sa karanasan ng mga mature mobile team.

Fail fast

Ang pinakamabilis na pagsusuri (linting, unit test) ay isinasagawa muna. Kung sila ay nabigo — ang pipeline ay nagtatapos nang hindi pinapatakbo ang mahabang UI test o pag-build ng release. Fail fast ay nakakatipid ng minuto ng CI time at nagpapabilis ng feedback sa developer. Ang average na oras hanggang sa unang pagkabigo ay hindi dapat lumampas sa 2–3 minuto.

Pag-cache ng mga dependency

Gradle cache, CocoaPods cache at SPM cache ay dapat ibalik sa pagitan ng mga run. GitHub Actions ay sumusuporta sa pag-cache sa pamamagitan ng actions/cache, GitLab CI — sa pamamagitan ng cache keyword. Kung walang pag-cache, ang bawat build ay nagdo-download ng lahat ng dependency mula sa simula — ito ay nagdaragdag ng 3–10 minuto sa oras ng pipeline.

Parallel execution

Ang mga independiyenteng yugto (linter para sa Android at iOS, unit test ng iba’t ibang module) ay pinapatakbo bilang parallel job. Ang parallelization ay nagpapababa ng kabuuang oras ng pipeline mula 20–30 minuto hanggang 5–10 minuto. Karamihan sa mga CI service ay nagbibilang ng parallel job nang hiwalay — isaalang-alang ito sa pagpili ng plano.

Pag-isolate ng environment

Ang bawat pagpapatakbo ng pipeline ay isinasagawa sa malinis na environment: Docker container, virtual machine o ephemeral runner. Ang pag-isolate ay pumipigil sa impluwensya ng mga nakaraang build sa kasalukuyang build. Iwasan ang paggamit ng shared runner sa pagitan ng mga proyekto — ang cross-project contamination ng environment ay humahantong sa non-deterministic na pagkabigo.

Seguridad ng mga secret

Ang mga API key, signing certificate at access token sa app store ay nakaimbak sa naka-encrypt na storage ng CI server. Huwag kailanman isama ang mga secret sa log, artifact o environment variable nang walang prefix na SECRET_. Gumamit ng mga tool tulad ng Fastlane match para sa pamamahala ng iOS certificate.