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

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

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

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

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

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

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

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

Есть.

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

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

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

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

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

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

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

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

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

:) а как у вас?