Если я правильно понял суть вопроса, то выход может быть следующим (в теории): создать «пустой» проект с тем же bundle id, что уже используется в приложении, добавить его в свой аккаунт Fabric через их утилиту, а дальше дистрибутив загружать из командной строки, как описано в разделе про Continuous Integration. Дополнительно можно последить за этой веткой: twittercommunity.com/t/add-new-ios-app-to-crashlytics-beta-via-command-line/56620 возможно что-то в будущем изменится.
Команда Fabric представила обновление сервиса Answers: answers.io/blog/introducing-answers-events — теперь есть возможность для отслеживания событий и дальнейшего анализа.
я старался рассматривать последнии версии сервисов, оценивать в ретроспективе, по-моему, не имеет смысла
Не очень понял, к чему это. Пару недель назад подсказывал коллеге, как сбросить глюканувший мастер интеграции. Пришлось общаться с техподдержкой, чтобы не потерять данные.
Из Вашего опыта, если я правильно понял, сложилась отрицательная оценка решения, которое использует Fabric, но при этом Вы отмечаете, что есть положительные изменения и проблемы, хоть и при вынужденном обращении к техподдержке, решаются. Поэтому мне, лично не столкнувшемуся с перечисленными проблемами, ситуация не кажется «катастрофической». Но я готов, если будут другие схожие отзывы, изменить оценку и выводы обзора.
В целом с выводами согласен, спасибо за цикл статей!
500 устройств — действительно факт, но странно, что он до сих пор не отражён даже в pre-release версии документации, там до сих пор говорится: Each individual or company can register up to 100 devices per membership year for development and testing.
You can register up to 100 of each device type (types: Apple TV, Apple Watch, iPad, iPhone, iPod Touch)
Спасибо, это хорошая новость — как я понимаю, изменение было сделано вместе с объединением всех типов developers program?
В статьях внесу исправления.
По поводу интеграции:
я старался рассматривать последнии версии сервисов, оценивать в ретроспективе, по-моему, не имеет смысла
мнение изложенное в обзоре априори субьективно, а сложности периодически возникают со всеми решениями (cocoapods, «вручную»)
в целом мне не кажется абсолютно верным подход/идеология Fabric, это я старался отразить в обзоре в целом, сервис не должен иметь узкой направленности на разработчиков
В идеале бы хотелось иметь сервис, совмещающий достоинства хотя бы всех перечисленных в обзоре сервисов, и не имеющий их недостатков. Надеюсь, рано или поздно, такой сервис появится.
Если не трудно, поинтересуйтесь пожалуйста у разработчиков Apple (если предоставится возможность), почему Springboard так сильно зависит от числа установленных приложений? Дольше выполняются операции по удалению приложений (переход в режим удаления), больше занято оперативной памяти — кажется что возможности для оптимизации должны быть, тем более у них. Ещё интересно как построена система QA у них, используют какие-то общедоступные сервисы/технологии или есть своё специализированное ПО? Пробовали ли они поставить на устройство 300-500 приложений и поработать с ним?
Разработчики Ubertesters держат своё слово: теперь при создании проекта возможно использовать загруженный дистрибутив в качестве первой ревизии. Плюс, как можно заметить на скриншоте, впереди нас ждёт обновление сервиса/SDK: будет возможна запись видео на тестируемых устройствах!
Формально такое использование Enterprise аккаунта будет нарушением соглашения с Apple, т.к. он предназначен для распространения ПО среди сотрудников одной компании.
Вопрос же целесообразности использования того или иного сервиса зависит от целей и особенностей проекта. Например, Ubertesters позволяет провести тестирование при специфических условиях (модель устройства, версия iOS и пр.) при привлечении внешних тестировщиков, а также имеет функционал предоставления более информативных отзывов. У других сервисов свои плюсы.
В настройках аккаунта можно изменить параметры отправления уведомлений для каждого из существующих триггеров:
публикация новой версии
создание новой crash-группы
получение нового отзыва
регистрация нового устройства пользователем
согласие пользователя на приглашение в команду
выход пользователя из команды
Доступные для выбора варианты:
ежедневно (дайджест)
индивидуально (для каждого события)
индивидуально и ежедневно
отключить
Символизация отчётов о падении выполняется постепенно, поэтому иногда в статистике можно видеть как группы, так и одиночные записи, хотя на самом деле причина падения может быть той же и в дальнейшем одиночные записи добавятся в соответствующую группу. Обычно для обработки и обновления статистики требуется около 5-10 минут.
На сайте сервиса в разделе «Mange App — Webhooks» Webhook Help содержит реальные данные из профиля приложения.
Каждое приложение (профиль) можно перенести на другой аккаунт (в другую организацию) без потери собранных данных. Очень удобно при смене команды или передаче проекта на аккаунт заказчика (и т.п. ситуации).
К сожалению, у меня он не отработал (не сработала проверка на втором, если не ошибаюсь, шаге), поэтому решил не упоминать.
Вообще изначально эта статья получилась 50+ страниц — после чего я приступил к правкам и сокращениям, так как уже получался не обзор, а руководство. Если кому-то интересно, то что-то из сокращенного могу добавить в комментариях.
Недостаток — в том смысле, что требует дополнительных усилий, например, нельзя отправить билд без иконок приложения, которых на ранних этапах проекта может и не быть, значит нужно будет сделать какой-то черновой вариант — временные затраты, конечно, могут быть и не значительными (можно получить все нужные иконки в онлайн-генераторе, например, makeappicon.com и пр.), но иногда, в зависимости от особенностей проекта и сложившейся практики управления проектами, могут оказаться и довольно ощутимыми. Также не всегда у разработчиков есть доступ к iTunesConnect (исходя из моего опыта работы в нескольких компаниях, нередко его либо предоставляют позднее, на завершающей стадии проекта, либо не предоставляют совсем).
В других же сервисах для распространения достаточно AdHoc-профиля — вот именно в таком сравнении, я считаю такую особенность недостатком.
Здесь мы получаем рабочую протестированную версию с нужным provisioning profile для того чтобы легко и без лишних сборок отправить билд в AppStore.
Это, конечно, плюс, но фактически нам ничто не мешает выполнить эту сборку один раз, перед релизом, даже если мы использовали другой сервис в ходе работы над проектом.
Спасибо! Эта часть скрипта действительно «кликает» на нужный переключатель.
Формально, исходя из целей обзора, я буду рассматривать только штатные способы работы с сервисами. Но в любом случае, хорошо, что уже есть «нештатные» средства, потому что в работе приходится решать конкретные задачи, а не писать обзоры и там уж не до формализма! Спасибо всем, кто делится своим опытом.
Спасибо за ссылку, посмотрел и мне кажется, что этот скрипт предназначен для публикации в AppStore, а не Prerelease версий.
versionInfo.releaseOnApproval.value — насколько я понимаю, чекбокс перед отправкой на обзор, чтобы приложение сразу же попадало в AppStore, в автоматическом режиме, сразу же как только будет одобрено (альтернативный вариант сделать это вручную, например, когда это привязано к каким-то маркетинговым мероприятиям и т.п.)
Если я правильно понял, речь идёт о iTMSTransporter и проблема, на мой взгляд, та же: нет возможности полностью автоматизировать распространение новой версии приложения. В iTunesConnect билд попадёт, но дальше нужно будет вручную всё делать. Если это не так, расскажите подробнее, пожалуйста.
Designing for Future Hardware — session 801
Доступно в приложении WWDC.
Из Вашего опыта, если я правильно понял, сложилась отрицательная оценка решения, которое использует Fabric, но при этом Вы отмечаете, что есть положительные изменения и проблемы, хоть и при вынужденном обращении к техподдержке, решаются. Поэтому мне, лично не столкнувшемуся с перечисленными проблемами, ситуация не кажется «катастрофической». Но я готов, если будут другие схожие отзывы, изменить оценку и выводы обзора.
Спасибо Вам за то что делитесь своим опытом!
Спасибо, это хорошая новость — как я понимаю, изменение было сделано вместе с объединением всех типов developers program?
В статьях внесу исправления.
По поводу интеграции:
В идеале бы хотелось иметь сервис, совмещающий достоинства хотя бы всех перечисленных в обзоре сервисов, и не имеющий их недостатков. Надеюсь, рано или поздно, такой сервис появится.
Вопрос же целесообразности использования того или иного сервиса зависит от целей и особенностей проекта. Например, Ubertesters позволяет провести тестирование при специфических условиях (модель устройства, версия iOS и пр.) при привлечении внешних тестировщиков, а также имеет функционал предоставления более информативных отзывов. У других сервисов свои плюсы.
В настройках аккаунта можно изменить параметры отправления уведомлений для каждого из существующих триггеров:
Доступные для выбора варианты:
Символизация отчётов о падении выполняется постепенно, поэтому иногда в статистике можно видеть как группы, так и одиночные записи, хотя на самом деле причина падения может быть той же и в дальнейшем одиночные записи добавятся в соответствующую группу. Обычно для обработки и обновления статистики требуется около 5-10 минут.
В десктопном приложении выбор типа релиза подразумевает, что все варианты, кроме Store, означают распространение дистрибутива через HockeyApp, в противном случае это Apple AppStore или Google Play market (http://support.hockeyapp.net/kb/about-general-faq/how-to-organize-development-and-production-apps)
Webhooks:
На сайте сервиса в разделе «Mange App — Webhooks» Webhook Help содержит реальные данные из профиля приложения.
Каждое приложение (профиль) можно перенести на другой аккаунт (в другую организацию) без потери собранных данных. Очень удобно при смене команды или передаче проекта на аккаунт заказчика (и т.п. ситуации).
ок, нужно будет попробовать ещё раз, если что, то внесу правки в соответствующий раздел.
Вообще изначально эта статья получилась 50+ страниц — после чего я приступил к правкам и сокращениям, так как уже получался не обзор, а руководство. Если кому-то интересно, то что-то из сокращенного могу добавить в комментариях.
В других же сервисах для распространения достаточно AdHoc-профиля — вот именно в таком сравнении, я считаю такую особенность недостатком.
Это, конечно, плюс, но фактически нам ничто не мешает выполнить эту сборку один раз, перед релизом, даже если мы использовали другой сервис в ходе работы над проектом.
Формально, исходя из целей обзора, я буду рассматривать только штатные способы работы с сервисами. Но в любом случае, хорошо, что уже есть «нештатные» средства, потому что в работе приходится решать конкретные задачи, а не писать обзоры и там уж не до формализма! Спасибо всем, кто делится своим опытом.
versionInfo.releaseOnApproval.value — насколько я понимаю, чекбокс перед отправкой на обзор, чтобы приложение сразу же попадало в AppStore, в автоматическом режиме, сразу же как только будет одобрено (альтернативный вариант сделать это вручную, например, когда это привязано к каким-то маркетинговым мероприятиям и т.п.)