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: Runners, Pipelines и Stages

Архитектура GitLab CI состоит из трёх ключевых компонентов. GitLab Runner — это агент, который выполняет jobs. Runners бывают shared (предоставляются GitLab), group (для группы проектов) и specific (для одного проекта). Каждый runner регистрируется с указанием executor: Shell, Docker, Kubernetes или VirtualBox. GitLab Runner поддерживает авто-масштабирование (auto-scaling) для обработки пиковых нагрузок.

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, в файле конфигурации, в group и project settings. Приоритет переменных определяется иерархией: trigger variables имеют наивысший приоритет, затем CI/CD variables из UI, затем из .gitlab-ci.yml. Переменные можно защитить (protected), что делает их доступными только для protected branches и tags.

Базовые переменные и образ

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 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 предлагает более гибкую модель 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, ценящих готовые действия и простоту настройки.

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

Пример пайплайна для Android-проекта

Полный пайплайн для Android включает: lint, unit test, сборку и деплой в Firebase App Distribution. Пайплайн использует Docker-образ с Android SDK, кеширование Gradle и параллельное выполнение lint и test в одной stage. Такой подход сокращает общее время пайплайна, так как tasks lint и test не зависят друг от друга.

Для iOS-проектов структура пайплайна отличается из-за необходимости macOS runner и code signing. Типовой iOS-пайплайн включает: установку 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

Оптимизация пайплайнов мобильной сборки в GitLab CI требует внимания к деталям. Правильная конфигурация cache и artifacts позволяет сократить время сборки в несколько раз. Для анализа производительности GitLab предоставляет CI/CD Analytics — дашборд с метриками длительности пайплайнов, загрузки runners и узких мест. Анализируйте эти метрики регулярно для поиска возможностей оптимизации. Настройка resource_group блокирует параллельный запуск одного пайплайна — это полезно для предотвращения конфликтов при деплое.

Также важна стратегия веток для CI. Рекомендуется запускать полный пайплайн только для main и release веток, а для feature-веток — только lint и unit-тесты. Это экономит минуты 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 с fallback на предыдущие ключи.

Docker-образ с предустановленными инструментами экономит время на установку. Рекомендуется создать кастомный образ с Android SDK, NDK и нужным API-уровнем. Параллельное выполнение jobs (lint, test, assemble) в разных stages сокращает общее время пайплайна. Pull policies для образов (if-not-present) ускоряют старт jobs. Также можно использовать dependency proxy для кеширования образов на уровне GitLab instance.

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