Comments 36
Автоматически заливать приложение в аппстор и Apple TestFlight можно с помощью вот этой штуки например:
Спасибо! Если правильно понимаю, то это только частично автоматизирует процесс — т.е. билд попадает в iTunesConnect, но все администрирование (вкл доступ для тестеров, выбрать тестеров, написать комментарий для билда) всё это нужно будет делать вручную.
+ А инструмент действительно интересный, проверю в действии, спасибо ещё раз!
Мы используем deliver как финальный этап непрерывной интеграции. Он очень многофунционален. А если вы используете сторонний build сервер(Jenkins, Bamboo etc.), то просто незаменим.
мне в этом плане нравится Beta by Crashlytics, при создании билда для откладки, выплывает окошко с предложением отправить билд тестерам и все. Для небольших команд это достаточно удобно
Спасибо за труд! Давно не следил за TestFlight, не знал, что их Apple выкупила и обрезала андроид.
Спасибо, очень вовремя статья. Жалко, что такой хороший продукт испортили. Что теперь делать с заливкой из коммандной строки не понятно пока. Придется либо искать алтернативы либо использовать deliver либо еще что-нибудь…
Ждем продолжения и в сложившейся ситуации — с нетерпением!
Ждем продолжения и в сложившейся ситуации — с нетерпением!
я надеюсь, что будет более тесная интеграция с CI via Xcode bots — это минимум, а дальше уже чем больше, тем лучше. Подождем беты следующей версии Xcode.
Эти боты — стременное го… но! Работали у меня несколько месяцев, выгружали автоматом на старый TestFlight мои сборки, по скрипту после архивирования. Так эти яблоки обновили свой сервер и чуть поменяли процесс архивации… добавили триггеры и ничерта не объяснили как ими пользоваться, какая-то мишура и пыль в глаза на презентации и чего дельного.
Мало того, работают боты хорошо только репозиториями а ля гитХаб… где надо платить деньги за то, что явно этого не стоит. Если кто читал статьи об автовыгрузке в TestFlight, наверное заметили общее негодование, как можно «научить» бота работать с самодельными ssh репозиториями…
Мало того, работают боты хорошо только репозиториями а ля гитХаб… где надо платить деньги за то, что явно этого не стоит. Если кто читал статьи об автовыгрузке в TestFlight, наверное заметили общее негодование, как можно «научить» бота работать с самодельными ssh репозиториями…
Prepare to flight!
Подобных сервисов много. Есть еще неплохие малоизвестные ребята типа getupdraft.com и buildozer.io/ которые делают сборки прямо из репы.
Еще несколько:
После обьявления об отключении testlfightapp.com думаем перейти на Crashlytics Beta для поддержки iOS7.
- hockeyapp.net ($)
- www.appaloosa-store.com ($/free)
- www.installrapp.com ($/free)
- www.applause.com/mobile-sdk ($/free)
После обьявления об отключении testlfightapp.com думаем перейти на Crashlytics Beta для поддержки iOS7.
Спасибо за трезвый взгляд! Думаю у многих возникла мысль об обходе ограничения в 100 устройств, при использовании «обычной» лицензии, для распространения так называемых Ad Hoc приложений среди тестеров. Думаю не многие компании сообразили как можно получить огромное количество пользователей и не ограничиваться 100 устройствами, а для рядовых разработчиков такая услуга вообще не предусмотрена. Думаю в ближайшее время найдется компания, отважный пират в этом океане, наполненном китами и акулами бизнеса, которая обойдет это ограничение даже без применения джейлбрейка, ну и станет лучшим сервисом для тестирования. Если такая уже не существует, может быть я о ней просто не знаю!
Извините за чайниковский вопрос? А почему «сервисы дистрибуции»? Это же сервис тестирования?
К слову, могу добавить комментарий об использовании сервиса с другой стороны — как пользователя. Я принимал участие в закрытом тестировании новой версии приложения itunes.apple.com/us/app/stackables-layered-textures/id704236938?mt=8
К самому процессу установки, обновления тестовой версии никаких вопросов нет. Всё работает как часы.
Но вот руководство по тестированию и приём отзывов команда разработчиков вела просто через email — потому что так пока удобнее, в комментариях к версии были только краткие инструкции.
Мне же, как внешнему тестеру, было неудобно вручную делать скриншоты, сопровождать их пометками и т.п. При наличии такого функционала в рамках сервиса, делать это было бы гораздо удобнее.
К самому процессу установки, обновления тестовой версии никаких вопросов нет. Всё работает как часы.
Но вот руководство по тестированию и приём отзывов команда разработчиков вела просто через email — потому что так пока удобнее, в комментариях к версии были только краткие инструкции.
Мне же, как внешнему тестеру, было неудобно вручную делать скриншоты, сопровождать их пометками и т.п. При наличии такого функционала в рамках сервиса, делать это было бы гораздо удобнее.
нет никаких гарантий, что Apple не приостановит или не прекратит его работу в любой момент
Ну сейчас там уже есть сообщение
The services offered at TestFlightapp.com will shutdown on 2/26/2015
Learn about the All-New TestFlight Beta Testing service available inside of iTunes Connect. For more information, please refer to our FAQ.
Написал письмо в TestFlightApp, там ответили, что можно использовать iTunes Transporter, оно как раз работает из консоли. Кстати он используется в Deliver проекте.
Если я правильно понял, речь идёт о iTMSTransporter и проблема, на мой взгляд, та же: нет возможности полностью автоматизировать распространение новой версии приложения. В iTunesConnect билд попадёт, но дальше нужно будет вручную всё делать. Если это не так, расскажите подробнее, пожалуйста.
Вы имеете ввиду релиз после сабмита? Да, такого нет. В Deliver пошли другим путем: github.com/KrauseFx/deliver/blob/master/lib/deliver/itunes_connect/itunes_connect_additional.rb#L39 просто сэмулировав нажатие кнопки на сайте.
Я еще полностью не изучил тонкости использования. Пока что мне было важно узнать как заливать из консоли. Не очень понравилось, что надо указывать логин-пароль в командной строке.
Я еще полностью не изучил тонкости использования. Пока что мне было важно узнать как заливать из консоли. Не очень понравилось, что надо указывать логин-пароль в командной строке.
Спасибо за ссылку, посмотрел и мне кажется, что этот скрипт предназначен для публикации в AppStore, а не Prerelease версий.
versionInfo.releaseOnApproval.value — насколько я понимаю, чекбокс перед отправкой на обзор, чтобы приложение сразу же попадало в AppStore, в автоматическом режиме, сразу же как только будет одобрено (альтернативный вариант сделать это вручную, например, когда это привязано к каким-то маркетинговым мероприятиям и т.п.)
versionInfo.releaseOnApproval.value — насколько я понимаю, чекбокс перед отправкой на обзор, чтобы приложение сразу же попадало в AppStore, в автоматическом режиме, сразу же как только будет одобрено (альтернативный вариант сделать это вручную, например, когда это привязано к каким-то маркетинговым мероприятиям и т.п.)
Эм, не только, если верить документации:
beta_ipa
A path to a signed ipa file, which will be uploaded and used for Apple TestFlight. After the upload was successful, it will wait until iTunesConnect processing is finished and submit the update to the testers. You have to add --beta to your deliver call to use beta_ipa instead of ipa.
github.com/KrauseFx/deliver/blob/master/lib/deliver/itunes_connect/itunes_connect_submission.rb#L11
тут, правда опять же эмуляция кликов, заливка бета версии для тестеров.
Вообщем на данный момент лучший вариант — использовать Deliver как я понимаю. Врядли чтото изменится. Но так как это стороний проект, то уверенности в будущем не особо есть :)
beta_ipa
A path to a signed ipa file, which will be uploaded and used for Apple TestFlight. After the upload was successful, it will wait until iTunesConnect processing is finished and submit the update to the testers. You have to add --beta to your deliver call to use beta_ipa instead of ipa.
github.com/KrauseFx/deliver/blob/master/lib/deliver/itunes_connect/itunes_connect_submission.rb#L11
тут, правда опять же эмуляция кликов, заливка бета версии для тестеров.
Вообщем на данный момент лучший вариант — использовать Deliver как я понимаю. Врядли чтото изменится. Но так как это стороний проект, то уверенности в будущем не особо есть :)
Спасибо! Эта часть скрипта действительно «кликает» на нужный переключатель.
Формально, исходя из целей обзора, я буду рассматривать только штатные способы работы с сервисами. Но в любом случае, хорошо, что уже есть «нештатные» средства, потому что в работе приходится решать конкретные задачи, а не писать обзоры и там уж не до формализма! Спасибо всем, кто делится своим опытом.
Формально, исходя из целей обзора, я буду рассматривать только штатные способы работы с сервисами. Но в любом случае, хорошо, что уже есть «нештатные» средства, потому что в работе приходится решать конкретные задачи, а не писать обзоры и там уж не до формализма! Спасибо всем, кто делится своим опытом.
Для распространения тестовых версий необходимо создать AppStore Distribution provisioning profile и настроить профиль приложения в iTunes Connect.
Это одно из самых важных преимуществ Apple TestFlight от остальных, а совсем не недостаток. Здесь мы получаем рабочую протестированную версию с нужным provisioning profile для того чтобы легко и без лишних сборок отправить билд в AppStore.
А что Вам мешает создать сборку подписанную нужным provisioning profile и отправить ее в любой другой сервис?
Так же во многих проектах где задействован сервер (API например), важно тестировать сначала dev, а затем prod версию. Как Вы соберете версию debug и зальете ее на Apple TestFlight? Обычно в таких случаях создают несколько схем, при сборке, в зависимости от схемы, определяют на какой URL «смотрит» приложение, получают нужную сборку и отправляют например в Crashlytics, а вот для Apple TestFlight такое уже не прокатит.
Apple TestFlight скорее уже альфа тестирование, нежели система для тестирования «сырых, рабочих» версий…
Так же во многих проектах где задействован сервер (API например), важно тестировать сначала dev, а затем prod версию. Как Вы соберете версию debug и зальете ее на Apple TestFlight? Обычно в таких случаях создают несколько схем, при сборке, в зависимости от схемы, определяют на какой URL «смотрит» приложение, получают нужную сборку и отправляют например в Crashlytics, а вот для Apple TestFlight такое уже не прокатит.
Apple TestFlight скорее уже альфа тестирование, нежели система для тестирования «сырых, рабочих» версий…
Я не исключаю AdHoc провижен и он безусловно полезен в процессе разработки и тестирования. Конечно, создаются дополнительные схемы с соответствующими ключами, чтобы управлять теми же ссылками на сервер, но несмотря на все предосторожности ошибки случаются. До запуска Apple Beta-Testing, продакшн версию никак нельзя было проверить, пока она не появится в AppStore. Например, могут забыть новый ключ для продакшн схемы или условие в коде, которое отвечает за миграцию базы данных, а при обновлении выяснится, что апп крашится. Apple TestFlight на данный момент не достаточен для того, чтобы перестать пользоваться другими сервисами на подобии HockeyApp и Crashlytics.
Недостаток — в том смысле, что требует дополнительных усилий, например, нельзя отправить билд без иконок приложения, которых на ранних этапах проекта может и не быть, значит нужно будет сделать какой-то черновой вариант — временные затраты, конечно, могут быть и не значительными (можно получить все нужные иконки в онлайн-генераторе, например, makeappicon.com и пр.), но иногда, в зависимости от особенностей проекта и сложившейся практики управления проектами, могут оказаться и довольно ощутимыми. Также не всегда у разработчиков есть доступ к iTunesConnect (исходя из моего опыта работы в нескольких компаниях, нередко его либо предоставляют позднее, на завершающей стадии проекта, либо не предоставляют совсем).
В других же сервисах для распространения достаточно AdHoc-профиля — вот именно в таком сравнении, я считаю такую особенность недостатком.
Это, конечно, плюс, но фактически нам ничто не мешает выполнить эту сборку один раз, перед релизом, даже если мы использовали другой сервис в ходе работы над проектом.
В других же сервисах для распространения достаточно AdHoc-профиля — вот именно в таком сравнении, я считаю такую особенность недостатком.
Здесь мы получаем рабочую протестированную версию с нужным provisioning profile для того чтобы легко и без лишних сборок отправить билд в AppStore.
Это, конечно, плюс, но фактически нам ничто не мешает выполнить эту сборку один раз, перед релизом, даже если мы использовали другой сервис в ходе работы над проектом.
Выше я написал ответ, к которому добавлю, что Apple Beta-Testing это скорее для тестирования Beta и больше Release Candidate версий. Всё же быстрое ревью неприятно замедяет тестирование приложения, которое находится на стадии разработки. В Apple Beta-Testing ещё многого не хватает по сравнению с другими сервисами, но уникальность тестирования продакшн версии, я считаю очень полезной и важной.
комментарий для третье части (сейчас и для TestFlight добавлю)
обновил раздел «Дополнительный функционал»: Apple добавили в последнюю версию Xcode новый функционал Crashes Organizer developer.apple.com/library/ios/recipes/xcode_help-crashes_organizer/AboutCrashesOrganizer/AboutCrashesOrganizer.html#//apple_ref/doc/uid/TP40015147-CH1-SW1
Sign up to leave a comment.
Сервисы дистрибуции мобильных приложений для iOS. Часть 1: TestFlight