GitLab CI: суштина, пајп лајнови и континуирана интеграција

Шта је GitLab CI?

GitLab CI је део јединствене DevSecOps апликације GitLab, која укључује континуирану интеграцију, испоруку и примену. Систем се појавио 2012. године као засебан пројекат, али је затим интегрисан директно у GitLab. Основни принцип — конфигурација као код (Configuration as Code) кроз датотеку .gitlab-ci.yml у корену репозиторијума. GitLab CI је доступан како у облачној SaaS верзији, тако и у self-managed инсталацији.

За мобилни развој, GitLab CI нуди аутоматизацију изградње APK и IPA, покретање инструменталних тестова, статичку анализу кода, потписивање апликација и објављивање у продавницама. Платформа подржава Docker слике за прилагођена окружења, што омогућава прединсталацију Android SDK, NDK, Xcode и других алата. Уграђени Container Registry поједностављује складиштење и дистрибуцију слика унутар тима.

Архитектура GitLab CI: Runner-и, Pipeline-и и Stage-ови

Архитектура GitLab CI састоји се од три кључне компоненте. GitLab Runner је агент који извршава jobs-ове. Runner-и могу бити shared (обезбеђује их GitLab), group (за групу пројеката) и specific (за један пројекат). Сваки runner се региструје са навођењем executor-а: Shell, Docker, Kubernetes или VirtualBox. GitLab Runner подржава ауто-скалирање за обраду вршних оптерећења.

Pipeline је скуп stage-ова који се извршавају секвенцијално. Унутар једног stage-а, jobs-ови се извршавају паралелно. Типична структура за мобилни пројекат: build → test → deploy. Ако се job на stage-у test заврши грешком, deploy се не покреће. Може се подесити ручно покретање (when: manual) за примену. Такође су подржани trigger-и multi-project pipelines за сложене CI/CD сценарије између репозиторијума.

Executor-и GitLab Runner-а

Docker executor је најпопуларнији за CI/CD мобилних апликација. Сваки job се покреће у чистом Docker контејнеру, што гарантује изолованост и поновљивост. За Android изградњу користи се слика android-sdk са прединсталираним SDK, за iOS — macOS runner са Shell executor-ом.

Конфигурација .gitlab-ci.yml за мобилне пројекте

Датотека .gitlab-ci.yml дефинише pipeline у YAML формату. Главне секције: image (Docker слика), stages (списак фаза), variables (променљиве окружења), before_script (команде пре сваког job-а) и сами jobs-ови са секцијама script, artifacts, cache. GitLab CI подржава include — повезивање спољних YAML датотека за поновну употребу заједничких конфигурација између пројеката.

Variables у GitLab CI могу се подесити на више нивоа: глобално у UI, у датотеци конфигурације, у поставкама групе и пројекта. Приоритет променљивих одређује хијерархија: trigger variables имају највиши приоритет, затим CI/CD variables из UI, па из .gitlab-ci.yml. Променљиве се могу заштитити (protected), што их чини доступним само за заштићене branch-еве и tag-ове.

Основне променљиве и слика

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 као артефакт. Артефакти се преносе између stage-ова — deploy job може користити APK из build-а. Рок чувања артефаката подешава се кроз 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: кључне разлике

При избору између GitLab CI и GitHub Actions за мобилни пројекат, важно је узети у обзир инфраструктуру тима. GitLab CI пружа уграђени Container Registry који се може користити за складиштење Docker слика са Android SDK. GitHub Actions се ослања на GitHub Packages или спољне регистре. GitLab такође има уграђени SAST (Static Application Security Testing) за анализу кода на рањивости.

GitLab CI нуди флексибилнији модел runner-а — подржава Kubernetes executor, ауто-скалирање и прилагођене слике. GitHub Actions побеђује у интеграцији са GitHub екосистемом и маркетплејсом actions-а. GitLab CI захтева ручну конфигурацију за многе задатке који се у GitHub Actions решавају готовим action-ом.

Са становишта CI/CD за мобилне пројекте: GitLab CI је погоднији за компаније које већ користе GitLab Self-Managed и захтевају self-hosted runnere са Docker/Kubernetes. GitHub Actions је згоднији за мале тимове на облачном GitHub-у, који цене готове акције и једноставност подешавања.

Поређење могућности

Пример пајп лајна за Android пројекат

Потпуни pipeline за Android укључује: lint, јединичне тестове, изградњу и примену у Firebase App Distribution. Pipeline користи Docker слику са Android SDK, кеширање Gradle-а и паралелно извршавање lint-а и тестова у једном stage-у. Овај приступ скраћује укупно време pipeline-а, јер задаци lint и test не зависе један од другог.

За iOS пројекте структура pipeline-а се разликује због потребе за macOS runner-ом и потписивањем кода. Типични iOS pipeline укључује: инсталацију CocoaPods или SPM, покретање тестова на симулатору, архивирање Xcode пројекта, извоз IPA и отпремање у TestFlight. GitLab CI за iOS користи macOS runner-е — било GitLab SaaS macOS runner-е са временским ограничењима, било self-hosted runner на 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

Оптимизација pipeline-ова мобилне изградње у GitLab CI захтева пажњу на детаље. Правилна конфигурација cache и artifacts омогућава смањење времена изградње вишеструко. За анализу перформанси, GitLab пружа CI/CD Analytics — командну таблу са метрикама трајања pipeline-ова, оптерећења runner-а и уских грла. Анализирајте ове метрике редовно да бисте пронашли могућности за оптимизацију. Подешавање resource_group блокира паралелно покретање једног pipeline-а — корисно за спречавање конфликата приликом примене.

Стратегија грана за CI је такође важна. Препоручује се покретање пуног pipeline-а само за main и release гране, а за feature гране — само lint и јединичне тестове. Ово штеди минуте runner-а и убрзава повратну информацију програмерима. GitLab CI подржава workflow:rules — условна правила за укључивање или искључивање jobs-ова у зависности од гране, измењених датотека или променљивих окружења.

Кеширање зависности је основни начин убрзања. GitLab CI кешира .gradle, Pods и node_modules између покретања. Кључ кеша укључује $CI_COMMIT_REF_SLUG или хеш lock датотеке. Време изградње Android пројекта се смањује са 10–15 на 2–4 минута уз правилно кеширање. Кеш може бити дистрибуиран — GitLab подржава cache:key са fallback-ом на претходне кључеве.

Docker слика са прединсталираним алатима штеди време на инсталацији. Препоручује се креирање прилагођене слике са Android SDK, NDK и потребним API нивоом. Паралелно извршавање jobs-ова (lint, test, assemble) у различитим stage-овима скраћује укупно време pipeline-а. Pull policies за слике (if-not-present) убрзавају покретање jobs-ова. Такође се може користити dependency proxy за кеширање слика на нивоу GitLab инстанце.

Још један важан аспект оптимизације је коришћење артефаката између фаза. Тешке датотеке APK и IPA боље је преносити кроз dependency, него поново изграђивати у сваком job-у. За велике пројекте са десетинама модула, препоручује се укључивање Gradle Build Cache на нивоу pipeline-а и подешавање remote cache-а на заједничком складишту. Timeout за сваки job треба поставити на основу очекиваног времена изградње — ово спречава заглављене процесе.

Пример са кеширањем и 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