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