Опыт мобильного CICD: один стандарт fastlane на много мобильных приложений

[alexovchinnicov]

Я так понял у вас в компании отсутсвует ReleaseEngineer/DevOps/Сисадмин и сборкой занимаються тестировщики? Из статьи совсем не понятно, где преимущество перед сборкой отдельными job'ами с хранением результата сборок в Nexus/Артифактори/etc? В каком шаге pipeline у вас тестирование на соответствие гайдланам Google Play и AppStore? Автоматизации тестирования мобильных приложений к примеру с популярным Appium тоже нет? Сразу деплоите в магазин и без подписей? Можете рассказать подробнее, а то складывается ощущение, что сделано не для удобства, а как дань моде?

[bshkrva]

у вас в компании отсутсвует ReleaseEngineer/DevOps/Сисадмин и сборкой занимаються тестировщики

Да. Сборкой мобильных приложений занимаются тестировщики. Это не сложно, тем более когда мобильщики помогают.

Из статьи совсем не понятно, где преимущество перед сборкой отдельными job'ами с хранением результата сборок

Не было цели показывать преимущество. Что именно включать в сборку, каким порядком запускать и каким образом — решать вам.

В каком шаге pipeline у вас тестирование на соответствие гайдланам Google Play и AppStore?

Что конкретно имеете в виду? Раскройте, я не поняла.
Ручное тестирование проводим после успешной загрузки альфа-сборки.

Автоматизации тестирования мобильных приложений к примеру с популярным Appium тоже нет?

Есть.

Сразу деплоите в магазин и без подписей?

Сначала подписываем, потом отправляем в альфу google play market и TestFlight. А у вас как?

Можете рассказать подробнее, а то складывается ощущение, что сделано не для удобства, а как дань моде?

Могу рассказать поподробнее.

В нашей компании процессом автоматизации разработки исторически начали заниматься тестировщики. Тестировщик тогда в компании был единственным, в свободное время погружался в ci/cd и понемногу внедрял каждый из шагов.
Так что поначалу наверное это была дань моде и желание достичь экономии в тестировании и разработке. В цифрах никто экономию не считал, но задачи свои процесс решает — разработчики не выливают приложения вручную, доступа до ключей подписи у них нет, запуск автотестов происходит до загрузки архива в сторы, тестировщики всегда в курсе, когда выходит новая сборка на тест (у нас нет необходимости вводить расписания релизов).

[alexovchinnicov]

А можно узнать название вашей компании? Вы пишите "… настроить шаблонный pipeline на CI и добавить ключи в репозиторий разработчика..." Из чего можно сделать вывод, что и безопасников у вас нет? Потому как хранить ключи для подписи в репозитории это совсем не хорошо по моему скромному мнению.

[bshkrva]

безопасников у вас нет

Отдельных нет, но мы к этому идём.

хранить ключи для подписи в репозитории это совсем не хорошо по моему скромному мнению.

Полностью с вами соглашусь — совсем не хорошо, и так у нас было на Android проектах до того, как переехали на этот процесс. Но даже это не так страшно, так как у нас развернут локальный Gitlab.
Выше в статье приведён пример Fastfile, где, к примеру, вызывается match — экшен, который подписью и занимается. Ключи живут в отдельном закрытом репозитории, куда доступ только у технической учетки и ребят, которые настраивали процесс. Как оно работает описано в codesigning guide . Аналогично сделали для ключей Android.

:) а как у вас?