Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Я так понимаю Hudson у вас установлен на Mac OS?
Ну а в целом вы конечно же конкретно урезали понятие CA до «всего лишь» подготовки билда для OTA (Over the Air) distribution, равзе что собирается он автоматически.
Как минимум в CI входят хотя бы юнит тесты, ну это ладно, если они в Xcode проекте есть, они обычно вместе с билдом выполняются.
Но и это не все, если открыть ту же самую статью в вики, только на английском, можно прочитать следующее
Мне бы было очень интересно прочитать статью о том, как делать regression тестирование для iOS с помощью того же Hudson, как запускать автоматически iOS симулятор и прогонять на нем тесты, или даже автоматически устанавливать билды на тестовые девайсы и выполнять тесты на них, и т.д. Еще интересно как автоматизировать тестирование мобильного UI в рамках CI и с помощью каких инструментов этого добиться, как, например, запустить много iOS симуляторов на разных виртуальных машинах, и автоматизировать весь процесс.
Ну а в целом вы конечно же конкретно урезали понятие CA до «всего лишь» подготовки билда для OTA (Over the Air) distribution, равзе что собирается он автоматически.
Как минимум в CI входят хотя бы юнит тесты, ну это ладно, если они в Xcode проекте есть, они обычно вместе с билдом выполняются.
Но и это не все, если открыть ту же самую статью в вики, только на английском, можно прочитать следующее
In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes.
Мне бы было очень интересно прочитать статью о том, как делать regression тестирование для iOS с помощью того же Hudson, как запускать автоматически iOS симулятор и прогонять на нем тесты, или даже автоматически устанавливать билды на тестовые девайсы и выполнять тесты на них, и т.д. Еще интересно как автоматизировать тестирование мобильного UI в рамках CI и с помощью каких инструментов этого добиться, как, например, запустить много iOS симуляторов на разных виртуальных машинах, и автоматизировать весь процесс.
>>> Я так понимаю Hudson у вас установлен на Mac OS?
Для запуска xcodebuild и пр. обязательно нужен slave на Mac OS.
При этом если собираетесь запускать симулятор, то Hudson нужно ставить не демоном (читай «из *.dmg»), а в userspace (читай «из *.war плюс скриптовая магия»).
В моём случае (не путать с автором статьи) это один mac mini, поскольку ведроидом пока не занимаюсь.
>>> Мне бы было очень интересно прочитать статью о том
А я-то думал, здесь все ну оооочень умные — вот и не пишу. Надо будет подумать над этим…
А пока вот вам немного устаревший материал.
Раз, Два
Обновлять пока смысла не вижу. И не я один такой
Для тестов использую calabash
Почитать про Build&Analyze можно в документации clang
Для запуска xcodebuild и пр. обязательно нужен slave на Mac OS.
При этом если собираетесь запускать симулятор, то Hudson нужно ставить не демоном (читай «из *.dmg»), а в userspace (читай «из *.war плюс скриптовая магия»).
В моём случае (не путать с автором статьи) это один mac mini, поскольку ведроидом пока не занимаюсь.
>>> Мне бы было очень интересно прочитать статью о том
А я-то думал, здесь все ну оооочень умные — вот и не пишу. Надо будет подумать над этим…
А пока вот вам немного устаревший материал.
Раз, Два
Обновлять пока смысла не вижу. И не я один такой
Для тестов использую calabash
Почитать про Build&Analyze можно в документации clang
В моём случае (не путать с автором статьи) это один mac mini, поскольку ведроидом пока не занимаюсь.
Ну по идее Mac OS вполне справится с Android, там весь тулчейн доступен практически для любой оси.
Надо будет подумать над этим…
Подумайте, что уж :) Мне эта тема как раз сейчас очень даже интересна. До этого момента занимался нативной разработкой под iOS, буквально через пару недель перехожу на новую работу, как раз на позицию связанную с тестированием мобильных приложений. Там все только начинается, еще даже не сделан окончательный выбор инструментов. Например, в плане автоматизации тестирования UI рассматривают вариант MonkeyTalk.
>>> Там все только начинается, еще даже не сделан окончательный выбор инструментов.
Итого, я пришел к следующему набору job-ов и инструментов.
Надеюсь, будет вам полезно.
1. OTA (Over the Air) distribution
Jenklins xCode plug-in + script для заливки в testflight. «Родной» testflight pug-in пока нормально настроить не получилось
Иногда собираю под симулятор когда QA «дрались» за device-ы (один смотрит на device, а другой — увы через iphonesim).
2. Static analyzer.
Clang «scan-build» с принудительным выставлением компилятора в тот, что поставляется с xCode
3. Unit test (Sen testing kit)
Обычный xcodebuild (не привязывая к application/library в качестве dependence).
Для них можно считать coverage с помощью gcovr + cobertura plug-in
4. gh-unit тесты
Гоняются через «iphonesim» и скриптовую магию (см. презентации по ссылкам выше). Coverage для них пока считать не умею
5. UI тесты
calabash + Jenkins TAP plug-in
6. Документация
Пока только appledoc. Latex еще не осилил (да и вряд ли понадобится).
Небольшой бонус для любителей framework-ов.
P.S. CocoaPods я не забыл, а намеренно не упомянул.
Итого, я пришел к следующему набору job-ов и инструментов.
Надеюсь, будет вам полезно.
1. OTA (Over the Air) distribution
Jenklins xCode plug-in + script для заливки в testflight. «Родной» testflight pug-in пока нормально настроить не получилось
Иногда собираю под симулятор когда QA «дрались» за device-ы (один смотрит на device, а другой — увы через iphonesim).
2. Static analyzer.
Clang «scan-build» с принудительным выставлением компилятора в тот, что поставляется с xCode
3. Unit test (Sen testing kit)
Обычный xcodebuild (не привязывая к application/library в качестве dependence).
Для них можно считать coverage с помощью gcovr + cobertura plug-in
4. gh-unit тесты
Гоняются через «iphonesim» и скриптовую магию (см. презентации по ссылкам выше). Coverage для них пока считать не умею
5. UI тесты
calabash + Jenkins TAP plug-in
6. Документация
Пока только appledoc. Latex еще не осилил (да и вряд ли понадобится).
Небольшой бонус для любителей framework-ов.
P.S. CocoaPods я не забыл, а намеренно не упомянул.
Ок, спасибо.
Интересует пара моментов по пунктам.
Негативные результаты static analyzer'а репортятся как ошибки и «забраковывают» весь билд?
И почему «намерянно не умпомянул» CocoaPods? Он каким-то боком не вписывается в процесс CI?
Сам использую pods, многие open source проекты полны warning-ов, а некоторые содержат код, который не нравится статическому анализатору, dead value storage, например, а иногда и вещи посерьезнее.
И насколько «зрелый» calabash? Тот же MonkeyTalk, про который я писал выше, имеет свои недостатки. Я взял очень простое приложение, которое использует только родные контролы, storyboard с обычными переходами и т.д. Запустил приложение, проделал простейшие действия, получил скрипт этого дела. Только выясняется, что в этом скрипте изначально не учитываются задержки между жестами, если его просто проиграть, приложение не успевает обработать действия так быстро. Но это мелочи, даже когда добавил задержки, все равно тот же скрипт не выполняется корректно, в самом конце он в упор откзывается «узнавать» кнопку по тегу, который сам же выдал в процессе записи. Другая проблема с UIGestureRecognizer'ами, напрмер обычный UITapGestureRecognizer вызывает селектор вроде — (void)handleTap:(UITapGestureRecognizer *)tgr. Абсолютно корректный код, работает без проблем в куче приложений, а в билде с включенным MonkeyTalk агентом входной параметр tgr внезапно становится объектом класса NSArray и вызов вроде tgr.state рушит приложение, как-будто MonkeyTalk агент занимается какой-то промежуточной магией и вставляет свои перехватчики где захочет, подменяя параметры своими мета-данными. Такой код уже и не протестируешь толком, разработчиков тоже не заставишь писать код с учетом недокументированного поведения MonkeyTalk агента. Т.е. проект во многом сырой и не выглядит как более-менее завершенный продукт, придется не только искать баги в своем приложении, но и разбираться, почему MonkeyTalk не работает.
Интересует пара моментов по пунктам.
Негативные результаты static analyzer'а репортятся как ошибки и «забраковывают» весь билд?
И почему «намерянно не умпомянул» CocoaPods? Он каким-то боком не вписывается в процесс CI?
Сам использую pods, многие open source проекты полны warning-ов, а некоторые содержат код, который не нравится статическому анализатору, dead value storage, например, а иногда и вещи посерьезнее.
И насколько «зрелый» calabash? Тот же MonkeyTalk, про который я писал выше, имеет свои недостатки. Я взял очень простое приложение, которое использует только родные контролы, storyboard с обычными переходами и т.д. Запустил приложение, проделал простейшие действия, получил скрипт этого дела. Только выясняется, что в этом скрипте изначально не учитываются задержки между жестами, если его просто проиграть, приложение не успевает обработать действия так быстро. Но это мелочи, даже когда добавил задержки, все равно тот же скрипт не выполняется корректно, в самом конце он в упор откзывается «узнавать» кнопку по тегу, который сам же выдал в процессе записи. Другая проблема с UIGestureRecognizer'ами, напрмер обычный UITapGestureRecognizer вызывает селектор вроде — (void)handleTap:(UITapGestureRecognizer *)tgr. Абсолютно корректный код, работает без проблем в куче приложений, а в билде с включенным MonkeyTalk агентом входной параметр tgr внезапно становится объектом класса NSArray и вызов вроде tgr.state рушит приложение, как-будто MonkeyTalk агент занимается какой-то промежуточной магией и вставляет свои перехватчики где захочет, подменяя параметры своими мета-данными. Такой код уже и не протестируешь толком, разработчиков тоже не заставишь писать код с учетом недокументированного поведения MonkeyTalk агента. Т.е. проект во многом сырой и не выглядит как более-менее завершенный продукт, придется не только искать баги в своем приложении, но и разбираться, почему MonkeyTalk не работает.
Цель статьи рассказать о различиях сборки для разных платформ.
В заключении статьи написано, что тестирование — наш следующий шаг и возможно, тема следующего поста :) А пока что unit тесты, как вы написали, прогоняются в режиме прошли/не прошли и никак системой сборки не анализируются.
Насчет regression тестирования — тоже очень хотелось бы реализовать, но это уже чуть позже. Если вообще получится.
Да, Hudson стоит на отдельном Mac OS. На нем установлены iOS и Android SDK
В заключении статьи написано, что тестирование — наш следующий шаг и возможно, тема следующего поста :) А пока что unit тесты, как вы написали, прогоняются в режиме прошли/не прошли и никак системой сборки не анализируются.
Насчет regression тестирования — тоже очень хотелось бы реализовать, но это уже чуть позже. Если вообще получится.
Да, Hudson стоит на отдельном Mac OS. На нем установлены iOS и Android SDK
А как с номерами версий у вас устроено дело? Допустим, есть текущая версия 7.0, над которой все работают, а надо выпустить срочно 6.4 SR, которая решает какие-то проблемы.
Сколько задач в hudson, как работаете с ветками в git, как скрипт сборки узнает «узнает» про номер версии.
Сколько задач в hudson, как работаете с ветками в git, как скрипт сборки узнает «узнает» про номер версии.
В hudson сейчас 12 задач.
Сама система собирает всегда из ветки master, если принудительно не указать другую при создании проекта.
Номер версии — инкремент при выполнении каждой задачи. Текущий номер берется из проекта xcode или eclipse.
Если нужно выпустить версию 6.4 SR, то все зависит насколько часто она будет востребована. Если она нужна один раз что закрыть баги — то это делает сам разработчик :( Если же это отдельные продукт, то в hudson создается новая задача для него и указывается отдельная ветка. При сборке соотвественно будет. что нибудь вроде 6.4.1, 6.4.2 и т.д.
Сама система собирает всегда из ветки master, если принудительно не указать другую при создании проекта.
Номер версии — инкремент при выполнении каждой задачи. Текущий номер берется из проекта xcode или eclipse.
Если нужно выпустить версию 6.4 SR, то все зависит насколько часто она будет востребована. Если она нужна один раз что закрыть баги — то это делает сам разработчик :( Если же это отдельные продукт, то в hudson создается новая задача для него и указывается отдельная ветка. При сборке соотвественно будет. что нибудь вроде 6.4.1, 6.4.2 и т.д.
>>> А как с номерами версий у вас устроено дело?
xCode plug-in умеет сам версию в нужный Info.plist «вшивать».
>>> Допустим, есть текущая версия 7.0, над которой все работают, а надо выпустить срочно 6.4 SR, которая решает какие-то проблемы.
То есть, вопрос «как вы пользуетесь git tag/branch»?
Каждый выбирает для себя. А иногда за вас выбирает начальство и заставляет сидеть на уродливом SVN…
xCode plug-in умеет сам версию в нужный Info.plist «вшивать».
>>> Допустим, есть текущая версия 7.0, над которой все работают, а надо выпустить срочно 6.4 SR, которая решает какие-то проблемы.
То есть, вопрос «как вы пользуетесь git tag/branch»?
Каждый выбирает для себя. А иногда за вас выбирает начальство и заставляет сидеть на уродливом SVN…
Bamboo как вариант вы не рассматривали? Мы в итоге остановились именно на Bamboo.
Интересно, но в качестве средства доставки приложений тестировщикам рассмотрите TestFlightApp.com
Работает с Adroind и iOS + предоставляет SDK для получения крашлогов.
Закачку можно автоматизировать, уведомлении о новых версиях тоже рассылаются, можно мониторить установки и конкретные версии приложений, управлять списками допущенных к тестированию отдельных проектов. Вообщем, очень рекомендую.
Работает с Adroind и iOS + предоставляет SDK для получения крашлогов.
Закачку можно автоматизировать, уведомлении о новых версиях тоже рассылаются, можно мониторить установки и конкретные версии приложений, управлять списками допущенных к тестированию отдельных проектов. Вообщем, очень рекомендую.
>>> Чтобы iPhone перейдя по ссылке начал устанавливать приложение, эта ссылка должна быть вида itms-services://?action=download-manifest&url=http://server/projectname.plist
У них там свой testflight — with blackjack and hookers. Чтобы враги не украли( дизассемблировали ) драгоценные приложения. git, небось, тоже сами хостят.
Корпорасты иногда выдвигают подобные требования…
У них там свой testflight — with blackjack and hookers. Чтобы враги не украли( дизассемблировали ) драгоценные приложения. git, небось, тоже сами хостят.
Корпорасты иногда выдвигают подобные требования…
Ну… маркеры у каждого свои, на вкус и цвет подобранные :)
На tesflightapp ты тоже закачиваешь уже готовые apk/ipa.
На tesflightapp ты тоже закачиваешь уже готовые apk/ipa.
Не обязательно «свой testflight». При разработке enterprise приложений, важной частью является OTA distribution, этот процесс нужно наладить, автоматизировать, если нужно, проработать все возможные варианты, учесть возможные особенности IIS или Mac OS серверов, и т.д. А TestFlight все это дело делает за разработчика. В целом, TestFlight прекрасен, конечно же, но в плане креш-логово мне на данный момент больше нравится Crashlytics, чисто субъективно, хотя у них еще даже нет своего пода в CocoaPods.
На данный момент у нас OTA реализован на том уровне который нам нужен был. А именно
— пользователь может оставить свой UDID
— администратор (как и в testFlight если я не ошибаюсь) должен прописать его в профиль
— пользователь заходит с устройства на сайт и тут же ставит себе приложение OTA
В TestFlight прикручены различные вкусности вроде уведомлений, приглашений и управления. Но нам пришлось отказаться от этого в угоду «безопасности». Хотя некоторые проекты мы оставили в TF )
— пользователь может оставить свой UDID
— администратор (как и в testFlight если я не ошибаюсь) должен прописать его в профиль
— пользователь заходит с устройства на сайт и тут же ставит себе приложение OTA
В TestFlight прикручены различные вкусности вроде уведомлений, приглашений и управления. Но нам пришлось отказаться от этого в угоду «безопасности». Хотя некоторые проекты мы оставили в TF )
Как уже написали — у нас свой TestFlight (с шахматами и поэтессами))
Именно по причине беспокойства заказчиков (как это вы наше приложение куда то залили?!)
Именно по причине беспокойства заказчиков (как это вы наше приложение куда то залили?!)
Попробуйте лучше jenkins — это тот же Hudson, но поэтессы красивее и в шахматах больше фигур.
так переход довольно простой — подмена варника и переименование папки с .hudson на .jenkins и потом уже борьба с совместимостью плагинов — это самое трудоемкое
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Continuous Integration для мобильных и веб-проектов