GitLab CI: същност, pipeline и непрекъсната интеграция

Какво е 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: Runners, Pipelines и Stages

Архитектурата на GitLab CI се състои от три ключови компонента. GitLab Runner е агентът, който изпълнява jobs. Runners могат да бъдат shared (предоставени от GitLab), group (за група проекти) и specific (за един проект). Всеки runner се регистрира с посочване на executor: Shell, Docker, Kubernetes или VirtualBox. GitLab Runner поддържа автоматично мащабиране за обработка на пикови натоварвания.

Pipeline е съвкупност от stages, изпълнявани последователно. В рамките на един stage jobs се изпълняват паралелно. Типична структура за мобилен проект: build → test → deploy. Ако job на stage test завърши с грешка, deploy не се стартира. Може да се конфигурира ръчно стартиране (when: manual) за внедряване. Поддържат се и тригери multi-project pipelines за сложни CI/CD сценарии между хранилища.

Executors на 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 като артефакт. Артефактите се предават между stages — 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 срещу 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 предлага по-гъвкав модел за runners — поддържа Kubernetes executor, автоматично мащабиране и персонализирани изображения. GitHub Actions печели в интеграцията с екосистемата GitHub и пазара за actions. GitLab CI изисква ръчна конфигурация за много задачи, които в GitHub Actions се решават с готов action.

От гледна точка на CI/CD за мобилни проекти: GitLab CI е по-подходящ за компании, които вече използват GitLab Self-Managed и изискват self-hosted runners с Docker/Kubernetes. GitHub Actions е по-удобен за малки екипи на облачния GitHub, които ценят готовите actions и простотата на конфигурация.

Сравнение на възможностите

Пример за pipeline за 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 runners — или GitLab SaaS macOS runners с времеви ограничения, или 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, натоварване на runners и тесни места. Анализирайте тези метрики редовно, за да откриете възможности за оптимизация. Настройката resource_group блокира паралелното стартиране на един pipeline — полезно за предотвратяване на конфликти при внедряване.

Стратегията за клонове за CI също е важна. Препоръчва се пълен pipeline да се стартира само за main и release клоновете, а за feature клоновете — само lint и единични тестове. Това спестява минути на runners и ускорява обратната връзка към разработчиците. GitLab CI поддържа workflow:rules — условни правила за включване или изключване на jobs в зависимост от клон, променени файлове или променливи на средата.

Кеширането на зависимости е основният начин за ускоряване. GitLab CI кешира .gradle, Pods и node_modules между стартиранията. Ключът за кеш включва $CI_COMMIT_REF_SLUG или хеш на lock файла. Времето за изграждане на Android проект се намалява от 10–15 на 2–4 минути при правилно кеширане. Кешът може да бъде разпределен — GitLab поддържа cache:key с връщане към предишни ключове.

Docker изображение с предварително инсталирани инструменти спестява време за инсталация. Препоръчва се създаване на персонализирано изображение с Android SDK, NDK и необходимото API ниво. Паралелното изпълнение на jobs (lint, test, assemble) в различни stages намалява общото време на pipeline. Pull policies за изображения (if-not-present) ускоряват стартирането на jobs. Може да се използва и dependency proxy за кеширане на изображения на ниво GitLab инстанция.

Друг важен аспект на оптимизацията е използването на артефакти между етапите. Тежките файлове APK и IPA е по-добре да се предават чрез dependency, отколкото да се преизграждат във всеки job. За големи проекти с десетки модули се препоръчва активиране на Gradle Build Cache на ниво pipeline и конфигуриране на отдалечен кеш в общо хранилище. 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