GitLab CI: esensya, pipeline at tuluy-tuloy na integrasyon

Ano ang GitLab CI?

GitLab CI ay bahagi ng pinag-isang DevSecOps application ng GitLab na sumasaklaw sa tuluy-tuloy na integrasyon, paghahatid, at pag-deploy. Ang system ay lumitaw noong 2012 bilang isang hiwalay na project, ngunit pagkatapos ay isinama nang direkta sa GitLab. Ang pangunahing prinsipyo — configuration bilang code (Configuration as Code) sa pamamagitan ng .gitlab-ci.yml file sa root ng repository. Ang GitLab CI ay available pareho sa cloud SaaS version at sa self-managed installation.

Para sa mobile development, nag-aalok ang GitLab CI ng automation ng pagbuo ng APK at IPA, pagpapatakbo ng mga instrumental na pagsubok, static na code analysis, pagpirma ng application, at pag-publish sa mga tindahan. Sinusuportahan ng platform ang mga Docker image para sa custom na kapaligiran, na nagbibigay-daan sa pre-installation ng Android SDK, NDK, Xcode at iba pang tool. Ang nakapaloob na Container Registry ay nagpapasimple ng pag-iimbak at pamamahagi ng mga image sa loob ng team.

Arkitektura ng GitLab CI: Runners, Pipelines at Stages

Ang arkitektura ng GitLab CI ay binubuo ng tatlong pangunahing bahagi. GitLab Runner ay ang ahente na nagsasagawa ng mga job. Ang runners ay maaaring shared (ibinibigay ng GitLab), group (para sa grupo ng mga project), at specific (para sa isang project). Bawat runner ay nagrerehistro na may pagtukoy ng executor: Shell, Docker, Kubernetes o VirtualBox. Ang GitLab Runner ay sumusuporta sa auto-scaling para sa paghawak ng peak load.

Ang pipeline ay isang koleksyon ng stages na isinasagawa nang sunud-sunod. Sa loob ng isang stage, ang mga job ay isinasagawa nang parallel. Karaniwang istraktura para sa mobile project: build → test → deploy. Kung ang isang job sa stage test ay nagtapos na may error, ang deploy ay hindi sisimulan. Maaaring i-configure ang manual na pag-start (when: manual) para sa pag-deploy. Sinusuportahan din ang mga trigger ng multi-project pipelines para sa mga kumplikadong CI/CD scenario sa pagitan ng mga repository.

Mga Executor ng GitLab Runner

Ang Docker executor ay ang pinakasikat para sa CI/CD ng mga mobile application. Bawat job ay pinapatakbo sa isang malinis na Docker container, na nag-gagarantiya ng isolation at reproducibility. Para sa Android build, ginagamit ang image android-sdk na may pre-install na SDK, para sa iOS — macOS runner na may Shell executor.

Configuration ng .gitlab-ci.yml para sa Mobile Projects

Ang .gitlab-ci.yml file ay nagde-definis ng pipeline sa YAML format. Mga pangunahing seksyon: image (Docker image), stages (listahan ng mga yugto), variables (environment variables), before_script (mga utos bawat bawat job) at ang mga job mismo na may mga seksyong script, artifacts, cache. Sinusuportahan ng GitLab CI ang include — pagkonekta ng mga panlabas na YAML file para sa muling paggamit ng mga shared configuration sa pagitan ng mga project.

Ang variables sa GitLab CI ay maaaring itakda sa maraming antas: global sa UI, sa configuration file, sa group at project settings. Ang priyoridad ng variables ay tinutukoy ng hierarchy: ang trigger variables ay may pinakamataas na priyoridad, pagkatapos ang CI/CD variables mula sa UI, pagkatapos mula sa .gitlab-ci.yml. Ang mga variable ay maaaring protektahan (protected), na ginagawang accessible lamang ang mga ito para sa protected branches at tags.

Mga pangunahing variable at image

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 ng pagbuo na may artifacts

Ang job generate-apk ay bumubuo ng Gradle project at nagse-save ng APK bilang artifact. Ang artifacts ay inililipat sa pagitan ng stages — ang deploy job ay maaaring gumamit ng APK mula sa build. Ang panahon ng pag-iimbak ng artifacts ay naka-configure sa pamamagitan ng expire_in.

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

GitLab CI vs GitHub Actions: Mga Pangunahing Pagkakaiba

Sa pagpili sa pagitan ng GitLab CI at GitHub Actions para sa mobile project, mahalagang isaalang-alang ang infrastructure ng team. Ang GitLab CI ay nagbibigay ng nakapaloob na Container Registry na maaaring gamitin para sa pag-iimbak ng Docker image na may Android SDK. Ang GitHub Actions ay umaasa sa GitHub Packages o panlabas na registries. Ang GitLab ay mayroon ding nakapaloob na SAST (Static Application Security Testing) para sa code analysis para sa mga vulnerability.

Ang GitLab CI ay nag-aalok ng mas flexible na modelo ng runner — sumusuporta sa Kubernetes executor, auto-scaling, at custom na image. Ang GitHub Actions ay nananalo sa integration sa GitHub ecosystem at actions marketplace. Ang GitLab CI ay nangangailangan ng manual configuration para sa maraming gawain na sa GitHub Actions ay nalulutas gamit ang ready-made action.

Mula sa pananaw ng CI/CD para sa mga mobile project: ang GitLab CI ay mas angkop para sa mga kumpanyang gumagamit na ng GitLab Self-Managed at nangangailangan ng self-hosted runners na may Docker/Kubernetes. Ang GitHub Actions ay mas maginhawa para sa maliliit na team sa cloud GitHub na pinahahalagahan ang ready-made actions at simpleng configuration.

Paghahambing ng mga kakayahan

Halimbawa ng Pipeline para sa Android Project

Ang kumpletong pipeline para sa Android ay kinabibilangan ng: lint, unit test, pagbuo at pag-deploy sa Firebase App Distribution. Ang pipeline ay gumagamit ng Docker image na may Android SDK, Gradle caching, at parallel na pagpapatakbo ng lint at test sa isang stage. Ang approach na ito ay nagpapababa ng kabuuang oras ng pipeline, dahil ang lint at test tasks ay hindi umaasa sa isa’t isa.

Para sa iOS projects, ang pipeline structure ay naiiba dahil sa pangangailangan ng macOS runner at code signing. Ang tipikal na iOS pipeline ay kinabibilangan ng: pag-install ng CocoaPods o SPM, pagpapatakbo ng mga test sa simulator, pag-archive ng Xcode project, pag-export ng IPA, at pag-upload sa TestFlight. Ang GitLab CI para sa iOS ay gumagamit ng macOS runners — alinman sa GitLab SaaS macOS runners na may limitasyon sa oras, o self-hosted runner sa Mac mini o 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

Pag-optimize ng Oras ng Pagbuo sa GitLab CI

Ang pag-optimize ng mga mobile build pipeline sa GitLab CI ay nangangailangan ng pansin sa detalye. Ang tamang configuration ng cache at artifacts ay nagbibigay-daan sa pagbawas ng oras ng pagbuo nang maraming beses. Para sa performance analysis, ang GitLab ay nagbibigay ng CI/CD Analytics — isang dashboard na may metrics tungkol sa tagal ng pipeline, load ng runners, at bottlenecks. Suriin ang mga metrics na ito nang regular upang makahanap ng mga oportunidad para sa pag-optimize. Ang setting na resource_group ay nagba-block ng parallel na pagpapatakbo ng isang pipeline — ito ay kapaki-pakinabang para maiwasan ang mga conflict sa pag-deploy.

Ang branch strategy para sa CI ay mahalaga rin. Inirerekomenda na patakbuhin ang buong pipeline para lamang sa main at release branches, at para sa feature branches — lamang lint at unit test. Ito ay nagse-save ng mga minuto ng runners at nagpapabilis ng feedback sa mga developer. Sinusuportahan ng GitLab CI ang workflow:rules — mga conditional na patakaran para sa pagsasama o pagbubukod ng mga job depende sa branch, binagong file, o environment variables.

Ang caching ng dependencies ay ang pangunahing paraan ng pagpapabilis. Ang GitLab CI ay nagca-cache ng .gradle, Pods at node_modules sa pagitan ng mga execution. Ang cache key ay may kasamang $CI_COMMIT_REF_SLUG o hash ng lock file. Ang oras ng pagbuo ng Android project ay nababawasan mula 10–15 hanggang 2–4 minuto na may tamang caching. Ang cache ay maaaring ipamahagi — sinusuportahan ng GitLab ang cache:key na may fallback sa mga nakaraang key.

Ang Docker image na may pre-install na tool ay nakakatipid ng oras sa pag-install. Inirerekomenda na gumawa ng custom image na may Android SDK, NDK at kinakailangang API level. Ang parallel na pagpapatakbo ng mga job (lint, test, assemble) sa iba’t ibang stages ay nagpapababa ng kabuuang oras ng pipeline. Ang pull policies para sa mga image (if-not-present) ay nagpapabilis ng pagsisimula ng mga job. Maaari ring gamitin ang dependency proxy para sa pag-cache ng mga image sa antas ng GitLab instance.

Ang isa pang mahalagang aspeto ng pag-optimize ay ang paggamit ng artifacts sa pagitan ng mga yugto. Ang mabibigat na file APK at IPA ay mas mainam na ilipat sa pamamagitan ng dependency kaysa itayo muli sa bawat job. Para sa malalaking project na may sampu-sampung module, inirerekomenda na i-activate ang Gradle Build Cache sa antas ng pipeline at i-configure ang remote cache sa shared storage. Ang timeout para sa bawat job ay dapat itakda batay sa inaasahang oras ng pagbuo — ito ay pumipigil sa mga nakabinbing proseso.

Halimbawa na may caching at pull policy

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

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