CI/CD в мобильном тестировании (GitLab)

CI/CD (Continuous Integration / Continuous Deployment) – это когда код автоматически проверяется, тестируется и выкатывается в продакшен, без шаманства с ручными релизами.

CI (Continuous Integration) – каждый коммит проверяется, тесты прогоняются, сборка не ломается.
CD (Continuous Deployment) – после успешных тестов всё деплоится (или выкатывается на тестовый сервер).

✅ Тесты гоняются автоматически → ты не тратишь время.
✅ Можно прогонять тесты на разных девайсах (реальных и эмуляторах).
✅ Быстро ловятся баги → меньше костылей в проде.

В GitLab CI/CD за процесс отвечает .gitlab-ci.yml – файл с инструкциями для пайплайна.

🛠 Pipeline – набор этапов, которые выполняются автоматически (сборка, тесты, деплой).
🔁 Job – отдельное задание внутри пайплайна (например, "Запусти UI-тесты").
📦 Stage – группа job'ов (например, "Тесты" → включает юнит-тесты и UI-тесты).
🔄 Runner – агент, который выполняет job'ы (можно настроить свой или использовать Shared Runners).
📂 Artifact – артефакты сборки (APK, лог-файлы тестов и т. д.).
🔀 Merge Request (MR) – запрос на слияние изменений в основную ветку.
🚀 Environment – среда, куда деплоится приложение (dev, staging, production).

Файл .gitlab-ci.yml – сердце CI/CD в GitLab. Здесь описываем, какие тесты и когда запускать.

Пример пайплайна для Android (Appium + Pytest):

stages: - test variables: ANDROID_HOME: "/sdk" PATH: "$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools:$PATH" test_ui: stage: test image: python:3.9 before_script: - pip install -r requirements.txt script: - pytest tests/ui_tests --junitxml=report.xml artifacts: paths: - report.xml

🔹 Что тут происходит?
✔ stages: Определяем этапы (у нас пока только test).
✔ variables: Переменные среды (Android SDK и путь к эмулятору).
✔ test_ui: Джоб, который запускает UI-тесты.
✔ image: Используем докер-образ с Python 3.9.
✔ before_script: Устанавливаем зависимости перед запуском.
✔ script: Запускаем тесты.
✔ artifacts: Сохраняем отчёт о тестах.

Чтобы GitLab выполнял тесты, нужен Runner – агент, который их запускает.

1 Устанавливаем GitLab Runner:

sudo curl -L --output /usr/local/bin/gitlab-runner \ "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64" sudo chmod +x /usr/local/bin/gitlab-runner

2 Регистрируем Runner:

gitlab-runner register

🔹 Вводим URL репозитория и токен (берём в Settings → CI/CD → Runners).

3 Запускаем Runner:

gitlab-runner start

Теперь тесты будут выполняться прямо на твоей машине или сервере.

Если нужно гонять тесты на Android:

test_android: stage: test image: budtmo/docker-android:emulator_11.0 before_script: - start-emulator - adb wait-for-device script: - pytest tests/android_tests

✔ budtmo/docker-android – докер-контейнер с эмулятором Android.
✔ start-emulator – запускаем эмулятор.
✔ adb wait-for-device – ждём, пока устройство загрузится.

Чтобы собирать APK (Android) или IPA (iOS) в GitLab CI/CD:

build_apk: stage: build image: openjdk:11 script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/apk/debug/app-debug.apk

build_ios: stage: build image: circleci/macos-xcode script: - bundle exec fastlane build artifacts: paths: - build/ios.ipa

Чтобы тесты запускались перед мержем:

1 Заходим в Settings → CI/CD → Pipelines.
2 Включаем Pipelines must succeed before merging.
3 Добавляем проверку в .gitlab-ci.yml:

test: script: - pytest rules: - if: $CI_MERGE_REQUEST_ID

Теперь перед мержем тесты должны пройти, иначе GitLab не даст слить ветку.

1 Разработчик пушит код в GitLab.
2 GitLab запускает пайплайн:

🏗 Сборка APK/IPA (Gradle, Fastlane).
✅ Запуск UI, API, Performance тестов (Appium, Espresso, JMeter).
📊 Сохранение артефактов (отчёты, скриншоты).
3 Если всё ок – можно мержить!

🔀 Создаём Merge Request (MR) – предлагаем влить изменения в основную ветку.
👀 Код-ревью – команда проверяет, нет ли косяков.
🔧 CI/CD проверяет тестами – если падают, фиксим.
✅ Мержим, если всё чисто – и код летит в дев/прод.

GitLab CI/CD – мощный инструмент для автоматизации тестирования.
Настроенный пайплайн = меньше ручных действий.
Merge Request + тесты = стабильный код в проде.
Android/iOS-сборка в CI/CD экономит кучу времени.

Теперь можно не руками запускать тесты, а просто мержить код и смотреть, как всё проверяется само.

CI/CD в мобильном тестировании (GitLab)

💡 Что такое CI/CD?

🔥 Зачем это мобильному тестировщику?

⚙ Как это работает в GitLab?

📌 Основные термины GitLab CI/CD

🔧 Настраиваем GitLab CI/CD для мобильных тестов

1 Создаём .gitlab-ci.yml

2 Подключаем GitLab Runner

Запускаем Runner на своём сервере

3 Добавляем Android-эмулятор в пайплайн

4 Автоматизация сборки APK/IPA

Android (Gradle)

iOS (Fastlane)

🛠 Автоматический запуск тестов при Merge Request

🚀 Полный цикл CI/CD для мобильного тестирования

📌 Как мержить код правильно?

🔥 Итог