Мощные CI/CD для DevOps-ориентированных команд
Разработка интеграции Kotlin Multiplatform и TeamCity
В этой статье я расскажу, как мы спроектировали и создали новую интеграцию TeamCity для Kotlin Multiplatform. Наше интерактивное руководство помогает KMP-разработчикам, создающим приложения для iOS, пройти путь от первого пуша в Git до протестированной сборки, релиза в TestFlight и полностью автоматизированного конвейера — и все это прямо в их IDE.
Делаем публикацию под iOS доступной
Публикация iOS-приложения зачастую является одним из самых сложных этапов разработки. Общаясь с разработчиками и изучая их рабочие процессы, мы постоянно слышали о одних и тех же проблемах:
- Для сборки под iOS требуется инфраструктура macOS, которая стоит дорого и незнакома многим кроссплатформенным разработчикам.
- Настройка сертификатов и профилей обеспечения (provisioning) от Apple — общепризнанное препятствие при первой публикации в App Store.
- Отсутствует понятный путь от IDE до запуска CI, а это значит, что по завершении работы над приложением разработчикам приходится разбираться с CI/CD полностью вне среды разработки.
Мы также заметили пробел с нашей стороны: ровно в тот момент, когда разработчик делает пуш в GitHub и думает: «Наверное, мне стоит настроить CI», — TeamCity нигде не видно.
Столкнувшись со всеми этими трудностями, мы поставили перед собой простую цель. Дать KMP-разработчикам под iOS возможность пройти путь от первого пуша до запуска iOS-конвейера с минимальной настройкой — без предварительных знаний CI/CD и без необходимости использования Mac. TeamCity Cloud предоставляет хостинговые агенты macOS и бесплатный начальный тарифный план с ежемесячным лимитом минут сборки, поэтому ничего не нужно подготавливать заранее, а попробовать все можно бесплатно.
Изучение концепции
Нашим руководящим принципом здесь было постепенное погружение. Мы запрашивали у разработчиков минимум информации, необходимой для текущего шага, переходя к следующему только после достижения чего-то конкретного.
Мы построили весь процесс вокруг этого принципа, выделив три этапа, каждый из которых дает разработчику осязаемый результат:
- Сборка и тестирование — плагин генерирует конфигурацию конвейера, создает рабочую область TeamCity Cloud, а также собирает и тестирует iOS-приложение на хостинговом агенте macOS, в результате чего разработчик получает успешную сборку и результаты тестов.
- Публикация — при настроенной подписи конвейер создает подписанную сборку и выгружает ее в TestFlight, впервые запуская приложение на реальном устройстве.
- Автоматизация — как только приложение успешно собирается и публикуется, мы предлагаем подключить репозиторий GitHub. С этого момента каждый пуш автоматически запускает конвейер, и CI/CD начинает работать самостоятельно.
Прежде чем приступать к созданию экранов, мы начали с картирования всего пути, состоящего в общей сложности из 10 шагов. Правильная последовательность (что запрашивать, когда запрашивать и что разработчик получает взамен) имела гораздо большее значение, чем любой отдельный экран.
Проверка дизайна
Дизайн прошел через множество итераций в тесном сотрудничестве с продуктовыми и инженерными командами. Открытые технические вопросы — где будут храниться сертификаты подписи, можно ли автоматически определить Bundle ID — решались совместно с командой до того, как соответствующие экраны были окончательно утверждены, а не оставлялись на потом в надежде вписать в готовый дизайн.
В июне мы провели около 10 модерируемых сессий по юзабилити с KMP-разработчиками, которые проходили полный прототип дизайна. Сессии подтвердили наши ожидания. Участники без опыта работы с CI/CD смогли пройти по направляемому пути, и это вело их до экрана успешного завершения. Они также выявили слабые места, которые мы устранили перед релизом.
Проектные решения
Встреча с разработчиком в нужный момент
Процесс запускается именно там, где возникает проблема. После того как разработчик делает пуш своего проекта, плагин KMP показывает подсказку с опцией настройки CI. Пользователи могут настроить CI без поисков, без изучения документации и не покидая IDE.
Установка плагина TeamCity становится частью того же процесса, а не отдельным шагом. Как только у разработчика возникает мысль: «Мне нужно настроить CI», — появляется TeamCity.
Разработчик сохраняет контроль
Плагин генерирует четыре файла: teamcity.yaml (определение конвейера), а также Fastfile, Appfile и Gemfile, отвечающие за публикацию. Все четыре файла отображаются для проверки перед началом первой сборки, они остаются локальными и не фиксируются в системе контроля версий.
Первая сборка запускается удаленно. TeamCity собирает и тестирует локальные файлы на хостинговом агенте macOS, чтобы разработчик мог убедиться в работоспособности конвейера до того, как что-либо попадет в систему контроля версий. Последним шагом всего процесса является самостоятельный коммит и пуш файлов конфигурации разработчиком.
Единая форма для подписи Apple
Подпись — это шаг, на котором сдается большинство начинающих издателей iOS-приложений. В нашем процессе этот шаг состоит из одной формы, в которой запрашиваются данные ключа API App Store Connect (идентификатор издателя, идентификатор ключа и секретный ключ .p8), идентификатор команды (team ID), идентификатор пакета (bundle ID) и сертификат дистрибутива. TeamCity сохраняет их как безопасные учетные данные развертывания.
В финальном варианте процесса экран поздравления с TestFlight зарезервирован для момента публикации приложения, а состояние завершения — для полностью настроенной автоматизации.
Что мы выпустили
Этот процесс проводит KMP-разработчика от подсказки в IDE после первого пуша через генерацию и проверку конвейера, создание учетной записи TeamCity Cloud, успешную сборку с результатами тестов и публикацию в TestFlight вплоть до автоматизации, запускаемой GitHub.
Как только репозиторий подключен, каждый пуш запускает сборку на хостинговом агенте macOS, выполняет тесты, подписывает приложение и выгружает его в TestFlight.
В документации Kotlin Multiplatform появился туториал по этому процессу: «Настройка конвейера доставки iOS для вашего проекта Kotlin Multiplatform», который теперь является частью стандартных руководств по публикации KMP.
Мы также отслеживаем, как пользователи продвигаются по процессу — от первого пуша до первого запуск конвейера, — чтобы видеть, где они успешны, где отсеиваются и что нужно улучшить в дальнейшем.
