Где был настроен CI на прошлом месте работы?

Конфигурация и инфраструктура CI/CD на проекте

На последнем месте работы Continuous Integration (CI) был настроен на основе GitLab CI/CD. Это была комплексная система, интегрированная непосредственно в GitLab-репозиторий проекта, что позволяло управлять всем циклом разработки — от коммита до деплоя — в единой платформе. Инфраструктура была развернута на собственных Linux-серверах (Ubuntu), что обеспечивало высокую степень контроля над конфигурацией и безопасностью.

Архитектура и основные компоненты CI

Конфигурация описывалась в файле .gitlab-ci.yml в корне репозитория. Система была разделена на несколько ключевых стей (stages), выполняемых последовательно:

• build — компиляция проекта и создание артефактов.
• test — запуск автоматических тестов (unit, integration).
• deploy — развертывание на целевые среды (staging, production).

Для iOS-проектов использовался следующий примерный конфигурационный блок для стадии build:

build_ios:
  stage: build
  image: xcode:latest  # Использовался специальный Docker-образ с Xcode
  script:
    - xcodebuild clean -project MyApp.xcodeproj -scheme MyApp
    - xcodebuild archive -project MyApp.xcodeproj -scheme MyApp -archivePath build/MyApp.xcarchive
    - xcodebuild -exportArchive -archivePath build/MyApp.xcarchive -exportPath build -exportOptionsPlist ExportOptions.plist
  artifacts:
    paths:
      - build/MyApp.ipa
    expire_in: 1 week

Ключевые особенности и практики

1. Автоматизация тестирования: В стадии test выполнялись не только Unit-тесты (Swift/XCTest), но и UI-тесты для критических пользовательских сценариев. Для этого использовались отдельные джобы (jobs) с конфигурацией, схожей с build, но с фокусом на запуск тестовых целевых (targets) в Simulator.

   test_unit:
     stage: test
     image: xcode:latest
     script:
       - xcodebuild test -project MyApp.xcodeproj -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 14'
   

2. Управление зависимостями и окружением: Для управления зависимостями использовался Swift Package Manager (SPM). В CI-скриптах предварительно выполнялась команда swift package resolve для обеспечения одинакового состояния зависимостей на всех этапах. Для работы с CocoaPods (в некоторых проектах) использовался кеширование папки Pods между запусками для ускорения процесса.

3. Деплой и артефакты: Процесс деплоя был автоматизирован. После успешного прохождения стадий build и test, созданный .ipa файл (артефакт) автоматически загружался на TestFlight для внутреннего бета-тестирования. Для этого использовался скрипт с Apple CLI tools (altool).

   # Пример скрипта для загрузки в TestFlight
   xcrun altool --upload-app -f build/MyApp.ipa -u "$APPLE_ID" -p "$APPLE_PASSWORD" --type ios
   

4. Безопасность и переменные окружения: Все чувствительные данные (Apple ID пароли, ключи API) хранились в защищенных переменных окружения (GitLab CI/CD Variables), которые были доступны только в контексте CI/CD и не попадали в логи.

5. Кеширование и оптимизация: Для значительного сокращения времени выполнения пайплайна было настроено кеширование (cache) директорий DerivedData и .build (для SPM). Это позволяло повторно использовать уже скомпилированные объекты при небольших изменениях в коде.

Интеграция с процессами разработки

CI-пайплайн был интегрирован с Git-ветвлением. Основные ветки (main, develop) всегда запускали полный пайплайн. Для feature-веток был настроен ускоренный пайплайн, который выполнял только стадии build и test_unit, чтобы быстро предоставить разработчику обратную связь о качестве кода. Также использовались GitLab Merge Requests, где статус пайплайна был обязательным условием для мержа изменений.

Таким образом, настроенная система CI представляла собой надежный, автоматизированный и безопасный конвейер для сборки, тестирования и подготовки релизов iOS-приложения, напрямую интегрированный в рабочий процесс команды.