Комментарии 13
Прям саксесс стори! Около года-полтора пытались начать пользоваться fastlane, но видимо звезды над нами встали не в том положении и оно не завелось. Интересно было бы почитать комментарии — есть ли кто еще использует этот инструмент? Ато как только новый релиз или вообще сабмит нового приложения, то это очередная боль, от которой все пытаются отмазаться.
У нас в компании используется fastlane в связке с jenkins. Нажимаем одну кнопку "скомпилировать", всё компилируется и выкладывается на testflight.
До такого уровня как в статье мы конечно не дошли — текст всеже пишется в itunes connect, но сборка автоматизирована полностью.
На самом деле с fastlane интересная история — пользуемся мы им относительно давно, во всем разобраться не смогли, поэтому часть вещей делаем странным образом — например сертификаты мы просто копируем сами в определенные папки, а не пользуемся возможностяами fastlane (возможно зря). У нас он из серии — работает не трож :)
Но один раз настроить (тут самое тяжелое как всегда провижены) и дальше радоваться жизни и не знать горя — оно того стоит.
Еще одна Success story. :)
Мы в ДругВокруг тоже используем Fastlane для автоматизации релизов. Тройка: Jenkins, Git, Fastlane работает вполне эффективно. Как и рассказывает автор статьи, нам тоже удалось сократить публикацию, правда, до банального коммита. :) Для справки, приложение так же мульти-язычное. Так вот, Fastlane позволил не только публиковать в Store тексты на всех поддерживаемых языках, но и полностью собирать локализации самого приложения, непосредственно в процессе сборки и отправки в App Store. В этом нам помогает сервис переводов OneSky.
Задачу с заливкой локализованных скриншотов решили тривиально — «Git в помощь». :) Дизайнер складывает все в подготовленную заранее структуру каталогов локализации (ru, en и т.п.), прямо в Finder-е и отправляет коммит. Оговорюсь сразу, для этого у дизайнера есть скрипт на импорт из Sketch. Но даже без него, скопировать несколько файлов откуда бы-то ни было в папку дело пяти секунд. В дальнейшем, эта структура заливается Fastlane, после сборки. Имена файлов, при этом не имеют значения. Важно только разрешение.
К слову, нам не пришлось написать ни одного кастомного интерфейса для оформления текстов для App Store. Все без исключение позволяет сделать Git Lab. Наглядно, безопасно, секурно. :) Все заинтересованные люди вносят изменения текстов в Develop ветку отдельного Git модуля. А перед отправкой релиза, когда тексты завалидированы, изменения сливаются в Master ветку и уходят в Store. Кто-то может раскритиковать такой подход, мол не удобно для маркетолога или менеджера проекта пользоваться Git Lab-ом. Может быть — а вы попробуйте. ;) Нашим удобно.
А еще, такая схема позволяет полностью воспроизвести ту или иную версию релиза в любой момент времени. Включая, мета данные для App Store, скриншоты, бинарник. И это может быть полезно.
Победа, конечно, далась не сразу, но это того стоило! Из последних трудностей — обновление App Store, в связи с выходом iOS 11. Новые ограничения и ужасное описание ошибок загрузки от Apple заставили потратить пару дней на адаптацию.
В целом, рекомендую всем и каждому!
Мы в ДругВокруг тоже используем Fastlane для автоматизации релизов. Тройка: Jenkins, Git, Fastlane работает вполне эффективно. Как и рассказывает автор статьи, нам тоже удалось сократить публикацию, правда, до банального коммита. :) Для справки, приложение так же мульти-язычное. Так вот, Fastlane позволил не только публиковать в Store тексты на всех поддерживаемых языках, но и полностью собирать локализации самого приложения, непосредственно в процессе сборки и отправки в App Store. В этом нам помогает сервис переводов OneSky.
Задачу с заливкой локализованных скриншотов решили тривиально — «Git в помощь». :) Дизайнер складывает все в подготовленную заранее структуру каталогов локализации (ru, en и т.п.), прямо в Finder-е и отправляет коммит. Оговорюсь сразу, для этого у дизайнера есть скрипт на импорт из Sketch. Но даже без него, скопировать несколько файлов откуда бы-то ни было в папку дело пяти секунд. В дальнейшем, эта структура заливается Fastlane, после сборки. Имена файлов, при этом не имеют значения. Важно только разрешение.
К слову, нам не пришлось написать ни одного кастомного интерфейса для оформления текстов для App Store. Все без исключение позволяет сделать Git Lab. Наглядно, безопасно, секурно. :) Все заинтересованные люди вносят изменения текстов в Develop ветку отдельного Git модуля. А перед отправкой релиза, когда тексты завалидированы, изменения сливаются в Master ветку и уходят в Store. Кто-то может раскритиковать такой подход, мол не удобно для маркетолога или менеджера проекта пользоваться Git Lab-ом. Может быть — а вы попробуйте. ;) Нашим удобно.
А еще, такая схема позволяет полностью воспроизвести ту или иную версию релиза в любой момент времени. Включая, мета данные для App Store, скриншоты, бинарник. И это может быть полезно.
Победа, конечно, далась не сразу, но это того стоило! Из последних трудностей — обновление App Store, в связи с выходом iOS 11. Новые ограничения и ужасное описание ошибок загрузки от Apple заставили потратить пару дней на адаптацию.
В целом, рекомендую всем и каждому!
А как решили проблему с загрузкой dSYM fastlane грузит только одну. после того как в релиз загружен в xCode можно скачать остальные.
И как автоматизированно создание релизной ветки? Номер сами выставляете или берете из настроек проекта?
И как автоматизированно создание релизной ветки? Номер сами выставляете или берете из настроек проекта?
Не очень понял вопрос про dSYM, можете как-то подробнее описать проблему?
По поводу релизных веток: название для новой ветки мы берем из текущих настроек проекта. При этом у нас есть различные механизмы по изменению версии в настройках:
* ручные, например, если мы решим выпустить версию {n+1}.0.0, надо будет самим поменять версию
* полуавтоматические, например, для ресабмита приложения (когда бинарник отклоняют после ревью) у нас есть кнопка Bump Version (видно на скринах в конце статьи)
* автоматическое, которое происходит после каждого релиза
Как-то так :)
По поводу релизных веток: название для новой ветки мы берем из текущих настроек проекта. При этом у нас есть различные механизмы по изменению версии в настройках:
* ручные, например, если мы решим выпустить версию {n+1}.0.0, надо будет самим поменять версию
* полуавтоматические, например, для ресабмита приложения (когда бинарник отклоняют после ревью) у нас есть кнопка Bump Version (видно на скринах в конце статьи)
* автоматическое, которое происходит после каждого релиза
Как-то так :)
Из iTunes connect их можно скачать как в ручном режиме так и в
автоматическом
автоматическом
Очень интересная статья, спасибо!
Отдельный вопрос есть по этому моменту:
Было бы очень интересно почитать, как вы работаете с переводами в мобильных приложениях.
У вас одно приложение поддерживает много языков, или вы выпускаете отдельные локализованные версии под разные рынки?
Какие инструменты используете для локализации мобильных приложений?
Как оно все работает «внутри» приложения?
Отдельный вопрос есть по этому моменту:
Сейчас у нас восемь iOS-приложений, большинство из них переводится на 25 языков и диалектов
Было бы очень интересно почитать, как вы работаете с переводами в мобильных приложениях.
У вас одно приложение поддерживает много языков, или вы выпускаете отдельные локализованные версии под разные рынки?
Какие инструменты используете для локализации мобильных приложений?
Как оно все работает «внутри» приложения?
У нас есть система переводов, где руками заводятся лексемы (атомарные кусочки текстов) на английском для дальнейшего перевода на другие языки.
Каждой лексеме присваивается уникальный строковый идентификатор (мы его называем system name)
При сборке приложения из системы переводов скачивается key-value структура.
Разработчики приложения используют system name для получения перевода на конкретный язык. В полученном переводе происходит замена плейсхолдеров переменных на значения. И потом перевод подставляется в шаблон.
Каждой лексеме присваивается уникальный строковый идентификатор (мы его называем system name)
При сборке приложения из системы переводов скачивается key-value структура.
Разработчики приложения используют system name для получения перевода на конкретный язык. В полученном переводе происходит замена плейсхолдеров переменных на значения. И потом перевод подставляется в шаблон.
Вот здесь про один из инструментов речь идет
habrahabr.ru/company/badoo/blog/338814
habrahabr.ru/company/badoo/blog/338814
Я человек простой, заюзал bitrise.io и горе админства не знаю. (конечно этот вариант лучше будет, у тех, у кого либо фриланс, либо 1.5 алпикашки в компании).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процесс релиза iOS-приложений в Badoo