Ответ
На проекте использовался Bitrise для iOS-приложений.
Причины выбора:
- Готовая интеграция с GitHub
- Оптимизированные шаги для iOS-сборок (поддержка CocoaPods, Swift Package Manager)
- Встроенное кэширование зависимостей для ускорения сборок
- Визуальный редактор конфигурации
Пример конфигурации Bitrise (bitrise.yml):
workflows:
primary:
steps:
- git-clone@6
- cache-pull@2
- cocoapods-install@2
- xcode-test@2:
inputs:
project_path: "Project.xcodeproj"
scheme: "Project"
simulator: "iPhone 15"
- cache-push@2Альтернативы: Для небольших проектов также использовали GitHub Actions из-за:
- Конфигурации в репозитории (
.github/workflows/) - Прозрачности и версионирования конфигов
- Бесплатного тарифа для публичных репозиториев
Ответ 18+ 🔞
А, ну это про наши мучения с CI/CD для айфоновских приложений, да? Так вот, блядь, раньше мы на Bitrise сидели, как приклеенные.
А почему, спрашивается, его выбрали? Ну, во-первых, он с GitHub сразу на раз-два скрещивается, без этих танцев с бубнами. Во-вторых, там уже всё для iOS-сборок заточено — CocoaPods, Swift Package Manager, всё это говно само ставится. И главное — кэш, ёпта! Он зависимости кэширует, так что не приходится каждый раз всю вселенную скачивать, сборки ускоряются просто овердохуища. Ну и конфиги там в визуальном редакторе щёлкать можно, что для ленивых, как я, — просто сказка.
Вот, смотри, как примерно конфиг выглядел (bitrise.yml):
workflows:
primary:
steps:
- git-clone@6
- cache-pull@2
- cocoapods-install@2
- xcode-test@2:
inputs:
project_path: "Project.xcodeproj"
scheme: "Project"
simulator: "iPhone 15"
- cache-push@2Но потом, блядь... Для мелких проектов-то мы на GitHub Actions переползли. А почему? Да потому что, сука, конфиги прямо в репозитории лежат (в этой папке .github/workflows/), всё прозрачно, как слёзы младенца, и версионируется вместе с кодом. И самое главное — для публичных репозиториев это бесплатно, блядь! Ну а кто ж от халявы откажется, верно? Вот и мотаемся между ними, как мартышлюшки.