Как настроен CI/CD на последнем месте работы?

Настройка CI/CD на последнем проекте

На последнем месте работы (команда из 8 iOS-разработчиков) мы использовали GitLab CI/CD с кастомной конфигурацией, адаптированной под нужды крупного банковского приложения. Конвейер состоял из нескольких стадий, выполняемых как на shared runner'ах, так и на dedicated macOS-агентах.

Архитектура пайплайна

.gitlab-ci.yml содержал следующие ключевые стадии:

stages:
  - validate
  - test
  - build
  - deploy
  - notify

Основные особенности:

1. Управление зависимостями - Использовали Cocoapods с кэшированием Pods/ и Rome для ускорения сборок
2. Кэширование артефактов - Стратегическое кэширование derived data и модулей
3. Параллельное выполнение - Тесты запускались параллельно на симуляторах разных версий iOS
4. Мультиконфигурационные сборки - Поддержка Development, Staging, Production окружений

Ключевые джобы и их реализация

1. Стадия валидации

validate_project:
  stage: validate
  script:
    - bundle exec fastlane run xcodebuild analyze
    - bundle exec fastlane run swiftlint
  only:
    - merge_requests

Использовали Fastlane для автоматизации и SwiftLint со строгими правилами code style. Для анализа кода применяли Xcode Static Analyzer.

2. Стадия тестирования

// Fastfile для unit-тестов
lane :run_unit_tests do
  scan(
    scheme: "MainApp",
    device: "iPhone 14",
    clean: true,
    code_coverage: true,
    output_directory: "./test_results"
  )
end

Покрытие тестами:

• Unit-тесты (XCTest) - минимальный порог 80%
• UI-тесты (XCUITest) для критических пользовательских сценариев
• Snapshot-тестирование через iOSSnapshotTestCase для визуальной регрессии

3. Стадия сборки

#!/bin/bash
# Скрипт сборки для разных конфигураций
set -eo pipefail

case $BUILD_CONFIGURATION in
  "Debug")
    xcodebuild clean build -scheme MainApp -configuration Debug
    ;;
  "Release")
    xcodebuild clean archive -scheme MainApp -configuration Release
    ;;
esac

Особенности сборки:

• Использовали Xcode Cloud для внутренних сборок
• Автоматическое управление версиями через agvtool
• Подписание через Match с разделением сертификатов по окружениям

4. Деployment процесс

deploy_to_testflight:
  stage: deploy
  script:
    - bundle exec fastlane beta
  only:
    - main
  artifacts:
    paths:
      - MainApp.ipa
    expire_in: 1 week

Каналы распределения:

• TestFlight для внутреннего тестирования (автоматическая загрузка при мерже в main)
• Firebase App Distribution для раннего доступа QA
• App Store Connect для production-релизов (ручное подтверждение)

Мониторинг и нотификации

Интеграции:

• Slack-уведомления о статусе сборок
• Sentry для отслеживания крешей на staging
• SonarQube для метрик качества кода
• Кастомные дашборды в Grafana для отслеживания производительности сборок

Оптимизации производительности

1. Стратегическое кэширование:

cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - Pods/
    - Carthage/
    - ~/Library/Developer/Xcode/DerivedData/
  policy: pull-push

1. Dependency caching - Предкомпиляция зависимостей при изменении Podfile.lock
2. Parallel test execution - Разделение тест-сьютов по группам
3. Conditional stages - Пропуск ненужных стадий для documentation-only изменений

Безопасность и секреты

• Использовали GitLab CI Variables с масками для чувствительных данных
• Fastlane Match для синхронизации provisioning profiles
• Ротация ключей подписи каждые 6 месяцев
• Аудит доступа к пайплайнам

Основные метрики и результаты

Производительность пайплайна:

• Полный цикл (от коммита до TestFlight): 18-25 минут
• Time to feedback для разработчиков: 3-5 минут (стадия validate + unit tests)
• Успешных сборок: 92% (после внедрения прекоммит-хуков)

Качество:

• Увеличили code coverage с 65% до 82% за 6 месяцев
• Сократили количество крешей в production на 40%
• Автоматизировали 95% рутинных операций по релизам

Проблемы и решения

Основные вызовы:

1. Флакки-тесты - Внедрили retry механизм и изоляцию тестов
2. Размер кэша - Регулярная очистка устаревших артефактов
3. Масштабирование - Переход на self-hosted runners при росте команды

Конфигурация постоянно эволюционировала с учетом feedback от разработчиков и меняющихся требований бизнеса. Ключевым успехом считаю баланс между скоростью выполнения и качеством проверок.