Выбор ответа Middle CI/CD, фича-флаги и релизы обновлено
Подпись на CI
Вопрос
Как правильно организовать подпись релизных сборок на CI?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Правильный ответ: Ключи и сертификаты в секретах CI или защищённом хранилище; на Android Play App Signing, на iOS API-ключ App Store Connect. Ключ подписи это доступ к обновлению приложения у всех пользователей.
Варианты ответа
- Хранить keystore и пароли в репозитории в зашифрованном архиве, чтобы любая сборка была воспроизводимой и не зависела от CI
- Подписывать релизы только на ноутбуке ведущего разработчика: ключ не покидает одну машину, и утечка с CI невозможна
- Ключи и сертификаты в секретах CI или защищённом хранилище; на Android Play App Signing, на iOS API-ключ App Store Connectправильный ответ
- Отключить подпись на CI для ускорения: магазин сам переподпишет сборку своим ключом при загрузке
Разбор
Ключ подписи это доступ к обновлению приложения у всех пользователей. Его не кладут в репозиторий, даже зашифрованным вместе с паролем рядом. С Play App Signing Google хранит ключ подписи приложения, а команда использует ключ загрузки, который можно сменить при утечке. На iOS удобно fastlane match или облачная подпись Xcode Cloud. Подпись «только на ноутбуке» это единая точка отказа, а неподписанную сборку магазин не примет: даже Play App Signing требует подписи ключом загрузки.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «CI/CD, фича-флаги и релизы»
- Обратная совместимость API для мобильных клиентов
- Метрика стабильности релиза
- Зачем фича-флаги в мобильном приложении
- Гигиена фича-флагов
- Хотфикс мобильного приложения
- Релизный пайплайн мобильного приложения
- Принудительное обновление
- Типы фича-флагов