Как настраивать автоматические коммиты и создание веток для релизов в Git workflow
Что проверяют
Умеете ли вы автоматизировать релизный процесс iOS-приложения без ручных правок версий и без хаоса в ветках. Следом обычно спрашивают, где хранятся номер версии и номер сборки и кто их увеличивает.
Как отвечать
Сначала уточните термин. Автоматический коммит в iOS-проекте это почти всегда коммит бампа версии и тег, которые делает CI, а не периодический git add . по расписанию.
- модель ветвления: Git Flow с
developиrelease/x.yподходит, когда релизы редкие и идут через ревью App Store с заморозкой кода. Trunk-based с короткими фича-ветками и веткойrelease/x.y, которую отрезают отmainперед отправкой на ревью, проще и сейчас встречается чаще; - версии: в Xcode это
MARKETING_VERSION(видит пользователь,CFBundleShortVersionString) иCURRENT_PROJECT_VERSION(номер сборки,CFBundleVersion). Номер сборки обязан расти с каждой загрузкой в App Store Connect; - fastlane: лейн релиза делает
ensure_git_status_clean,increment_build_number,build_app,upload_to_testflight, затемcommit_version_bump,add_git_tagиpush_to_git_remote. Номер сборки удобно брать изlatest_testflight_build_numberплюс один или из номера джобы CI; - создание ветки: отдельная джоба на macOS-раннере или в Xcode Cloud по кнопке или по расписанию отрезает
release/x.yотmain, поднимаетMARKETING_VERSIONи пушит; - защита: коммиты от CI идут от бот-аккаунта с токеном, которому разрешён пуш в защищённую ветку, а в сообщении стоит
[skip ci], чтобы бамп не запускал сборку по кругу.
Фиксы в релизную ветку вносите одним способом на всю команду: либо cherry-pick из main, либо обратный мерж релизной ветки.
Где спотыкаются
Предлагают скрипт по cron с git add . и пушем в main. В репозиторий уедет всё подряд, включая мусор и незаконченные правки, и ни одна проверка это не остановит.
Путают номер версии с номером сборки и получают отказ App Store Connect при повторной загрузке с тем же номером.
Забывают про зацикливание: CI коммитит бамп, коммит запускает CI, тот снова бампит.