Примечание: Продолжение большой статьи про непрерывную интеграцию первая часть здесь

В предыдущем посте я рассказал о том, как создавать определение сборки с помощью VSTS и как самостоятельно настраивать агента сборки на Mac.

В этом посте я расширю это определение сборки, так что мы сможем автоматически публиковать наше приложение на HockeyApp. Кроме того, я объясню, каким образом можно сделать то же самое с приложениями Android (за что следует также поблагодарить Ричарда Вулкота), и поделюсь полезной информации о других опциях, таких как Bitrise и AppVeyor.

Сперва давайте перенесем приложение на HockeyApp с целью цифровой дистрибуции, дабы оно стало доступным нашим фанатам.

Непрерывная интеграция при помощи HockeyApp

Прежде всего позвольте мне начать с плохих новостей.

Если Вы привыкли работать с Insights, то приготовьтесь: наступают тяжёлые времёна.

Сейчас платформа HockeyApp ориентирована только на жёсткие сбои, что подразумевает невозможность обработки исключительных ситуаций.

Получается, тут нет удобных графиков, сообщений об обработке исключений, незначительного пользовательского трекинга и т.д. Кроме того, SDK пока что не готов к формам и его структура в настоящие время не является безупречной.

Мне сообщили, что SDK в ближайшее несколько недель получит обновление, что неплохо, но HockeyApp в обозримой перспективе вряд ли сравнится по возможностям с Insights.

Есть другой момент, который касается дистрибуции приложения при помощи HockeyApp. В случае с iOS Вам придётся собрать целевые пользовательские UUID/UDID.

Это не сильно проблематично, ведь HockeyApp даже помогает собирать их с пользователей, но только тут есть одна шероховатость, потому как нам все равно придётся возвращаться к Apple, импортировать UUID, генерировать файл mobileprovision, и после того передавать его обратно HockeyApp.

Это главные минусы на сегодняшний момент. Но, к счастью, присутствует также и много плюсов! Так что давайте просто разберёмся в том, как мы можем отправить приложение на HockeyApp непосредственно из VSTS.

Определение сборки

Фактически, делается это двумя путями: можно добавить окончательный этап к определению сборки либо же перейти к релизной части среды VSTS.

Оба варианта являются эффективными, и в результате получается практически одно и тоже, однако в случае с методом релиза у Вас окажется больше контроля над тем, когда именно версия будет выпущена. Кроме того, в этом случае есть возможность позволить кому-то из пользователей заранее подписаться на релиз, и т.д. Я здесь опишу именно данный способ, то есть, как осуществляется выпуск приложения с помощью параметров релиза в VSTS.

Прежде всего, давайте вернемся к нашему определению сборки. Как вы можете видеть, я уже расширил его немного со времени предыдущего поста.

И вот, что здесь самое интересное: версия сборки.

В Ваших интересах вести правильный учёт того, какие версии приложения посылаются тестировщикам или даже в магазин приложений. Поэтому в случае возникновения ошибки можно будет задать главный вопрос: «на какой версии приложения появилась проблема?». Кроме того, если у вас есть опыт в области разработки программного обеспечения, вы, вероятно, периодически забываете об необходимости увеличивать номер версии приложения. Поэтому, если мы так любим всё автоматизировать, то почему бы не сделать это и данном случае?

Ведь приложения Xamarin по-прежнему остаются программами iOS, Android и UWP, когда дело касается этого вопроса, и поэтому здесь необходимо предпринять определённые действия с целью реализации требуемой функциональности, которые разнятся в зависимости от того, под какую платформу ведётся разработка. Например, iOS требует в этом случае обновления номера версии в файле info.plist. Это можно сделать с помощью простого регекса. После ряда самостоятельных изысканий, я наткнулся на этот пост: Versioning за авторством Ричарда Вулкота, где весь процесс превосходно описан для каждой платформы. Большое ему спасибо!

Кроме того, я добавил пункт по поводу удаления файлов .ipa. Я не уверен в том, что ничего не сломал в настройке параметров, но все мои сборки теперь идут в датируемые вложенные папки, которые эффективно снабжают меня большим количеством файлов ipa. Дабы убедиться в том, что всё получается и загрузка в HockeyApp идёт, я просто очищаю мою папку артефактов от всех файлов ipa, прежде чем создавать новые.

Этап Test Cloud отключен — я передаю его другому определению сборки.

Последней этап, позволяющий привести это всё в рабочие состояние, является здесь одним из самых интересных. На этом этапе нужно упаковать файлы ipa (или же apk в случае с Android) и опубликовать их в качестве некоего артефакта. Вы также можете включить туда файл dSYM, благодаря чему stacktraces (трассировка стека) получит больше информации в HockeyApp.

Разумеется, в случае с Android и UWP понадобятся эквиваленты этих файлов.

Можете достать любой нужный Вам файл путём указания правильных подстановочных знаков для доступа к ним.

С помощью поля типа Artifact можно определить место, где помещаются артефакты. Если Вы используйте Server, он будет переносить их обратно к главному серверу сборки (вероятно, к веб-порталу TFS, на который Вы сейчас смотрите), или Вы можете выбрать fileshare и указать путь к папке, куда нужно их поместить. Разумеется, у Вас должны иметься необходимые права на манипуляции с файловой системой, чтобы это сделать.

После того как всё будет сохранено, можно приступать к развертыванию! Поэтому сохраните всё и перейдите на верхнюю вкладку Release.

Определение релиза

Создание релиза крайне схоже с определением сборки. Здесь Вы можете также определить этапы, которые должны быть выполнены, с тем чтобы создать релиз.

Для того чтобы создать новый релиз, нажмите на большой «плюс» в левой колонке. В моём случае будет Boodschappie для iOS. Напомню, что Boodschappie является проектом, над которым я работаю в настоящие время, и скоро состоится его релиз.

После клика по нему должны появиться специальные шаблоны, которых на момент написания этой статьи всего два, и они оба имеют отношение к Azure. И поскольку мы не планируем размешать наше приложение на Azure, давайте выберем пустой шаблон внизу и нажмём на кнопку Next.

Теперь нам нужно указать, какому определению сборки этот релиз соответствует, так что релиз не может существовать без определения сборки.

Вместе с тем, так же, как Вы создаёте здесь определение сборки, можете тут отметить поле непрерывной интеграции, в результате чего релиз будет создаваться каждый раз, когда Вы записываете (checkin) код.

В любом случае Вам это может пригодиться. Есть несколько методов для определения того, должен ли релиз быть сделан (путём указания конкретной ветки проекта) или того, кто получит созданный релиз. Мы подойдём к этому чуть позднее.

После того как все настройки здесь будут завершены, просто нажмите на кнопку Create и через секунду определение релиза будет готово.

Среда релиза

Возможно, Вы и сами уже это заметили, но конструирование определения релиза является крайне схожим с созданием определения сборки. То же самое можно сказать и о добавлении этапов к определению, которые на самом деле называются задачами для релиза. Однако, тут имеется одна большая разница. Слева от того места, где Вы находитесь, когда добавляете в релиз этапы, можно увидеть дополнительный столбец. Он предназначен для сред.

Так же как и в случае с этапами, среды добавляются путём нажатия на кнопку «плюс». С помощью этой (казалось бы, простой) функциональности Вы получаете довольно много контроля над процессом релиза.

Среда является платформой, для которой Вы желаете выпустить приложение. Это может быть всё что угодно — от zip’а со сборкой WPF или пакета развертывания веб-приложения до файлов ipa, если речь идёт об iOS. Ведь различных проектов, в которых Вы можете это использовать, множество, и в том числе среди них Azure, HockeyApp и общие файловые ресурсы. Вы можете не только определить фактическую платформу для релиза, но у Вас также есть возможность ввести в действие механизм, где Вы назначаете утверждающих, которые решают является ли результат сборки достаточно хорошим для её релиза в следующую среду.

Получается, у Вас есть мощный инструмент, позволяющий убедиться в том, что сборки сперва отправляются к тестировщикам, прежде чем они попадают в среду UAT. Или осуществить его релиз на каком-нибудь промежуточном слоте Azure, запустить некоторые (автоматизированные) тесты с целью убедиться в том, что приложение может быть достигнуто и действует согласно тому, как ему положено, и только после этого выпустить его в продуктив. Гениально!

Релиз в HockeyApp

Как бы то ни было, именно сейчас мы не собираемся делать все эти продвинутые вещи, мы просто будем придерживаться одной среды, которая будет утверждаться автоматически. В действительности таковы установки среды по умолчанию, поэтому пока что примите это как должное и нажмите на кнопку добавления задач (Add tasks).

Когда Вы будете автоматически направлены на вкладку Deploy, обратите внимание на то, что все остальные этапы задачи также для Вас доступны. Можно запустить некоторые дополнительные задачи, если Вам нужно. Хотя HockeyApp в настоящие время является частью Microsoft, задача HockeyApp пока что не находится в списке по умолчанию. Но не волнуйтесь! Microsoft создала рынок программного обеспечения для всего, что связано с разработкой и релизом. Поэтому покликайте немного дальше; всё ещё не видите того, что вам нужно? Пройдите по ссылке и найдёте расширение HockeyApp.

Вообще-то всё довольно очевидно.

Затем найти его в списке и нажмите кнопку Add.

Этот этап требует немного большего, чем предшествовавшие конфигурации. Давайте в этом разберёмся.

Начинается всё со сложного: от Вас требуется указать соединение HockeyApp. Хотя постойте! У нас же его нет!

Сейчас я исхожу из того, что к настоящему времени у Вас уже имеется учетная запись в HockeyApp. Кроме того, подразумевается, что у Вас также есть созданное приложение. Несмотря на то что файлы ipa или apk загружаются крайне просто, делать это всё-таки приходится вручную. Теперь обратите внимание на ключ API в настройках учетной записи и идентификатор приложения (App ID) на его панели.

Далее, с тем чтобы создать соединение, ознакомитесь со страницей документации HockeyApp. После того как Вы успешно с этим справитесь, данные должны будут отображаться в выпадающем списке соединения HockeyApp. Заполните в следующем окне App ID и самая трудная часть на этом закончена!

И последнее, что нам нужно здесь сделать, — это указать путь к файлу ipa (или apk, если работа ведётся с Andoid-приложением). Поскольку наше определение релиза связано с определением сборки, помните о том, что путь к файлу здесь следует структуре артефакта, который мы исключаем. По правде говоря, это, вероятно, многое для нас упрощает, так как артефакт, возможно, содержит только один файл ipa, который мы можем вывести с помощью **\*.ipa, что посылает любые ipa-файлы к HockeyApp.

Кроме того, для целей удобочитаемости отчетов об ошибках добавьте файл dSYM в случае с iOS-релизом. Запомните: он непременно должен присутствовать в артефакте, если Вы желаете отправить последний на HockeyApp!

Остальным полям также стоит уделить внимание. Можно также включить примечания к релизу напрямую из проекта с файлом, уведомив тем самым о нём пользователей (HockeyApp) равно как и позволив системе определить, какие пользователи получают эту версию путем настройки тегов и/или групп и/или пользователей. Обратите внимание: это — сущности HockeyApp! Можете вдоволь с ними поиграть!

Когда закончите, нажмите на кнопку Save, дайте релизу надлежащие название и поверьте, как он работает. Для этого необходимо чтобы у Вас уже был успешный билд из соответствующего определения сборки. Теперь нажмите на кнопку Release, с тем чтобы выпустить версию.

Сейчас нужно просто выбрать артефакт, который Вы хотите использовать из этой сборки и нажать на кнопку Create. Теперь Вы вернетесь к фантастическому экрану ведения отчётов, где можно почувствовать себя настоящим хакером. Внимательно изучите выводимые данные, чтобы убедиться в том, что всё идёт хорошо. Как и в случае с созданием сборки, вероятно, потребуется предпринять несколько попыток, прежде чем Вам удастся сделать всё правильно.

Однако, в том случае, если всё пройдёт удачно, к Вам на почту должно поступить письмо из аккаунта в HockeyApp с сообщением о том, что новая версия стала доступной! Класс!

И что же теперь по поводу Bitrise?

Система VSTS — это замечательная вещь, и она, к тому же, является полностью завершенной, поэтому если вы работаете со всеми продуктами Microsoft, то почему бы не продолжать их придерживаться?

Единственная загвоздка здесь — это то, что потребуется какой-нибудь Mac либо же придётся заплатить за MacInTheCloud, но я обещал Вам нечто бесплатное! Собственно именно здесь-то и вступает в дело Bitrise.

Bitrise.io замечателен! Он способен выполнить все, что делает VSTS (в вопросе разработки и релиза), а также многое другое! Я не собираюсь здесь и сейчас описывать весь процесс, поскольку читатели могут заскучать из-за обилия новой информации. Однако, если к этой теме проявят достаточно внимания, я непременно подготовлю специальный материал по этому вопросу.

Но все-таки я добавлю, что на этом ресурсе аккаунт можно создать бесплатно, и они также обеспечивают пользователей Mac’ом, который требуется для разработки приложения под iOS! Нереально круто!

Так же, как и на VSTS, тут можно произвести в полном объеме собственную сборку и осуществить её релиз. И у них также есть похожее на рынок программного обеспечения хранилище с этапами сборки. И оно в настоящий момент является более завершенным, чем аналогичное решение у VSTS.

Отсутствует некий этап? Вы можете легко создавать их самостоятельно!

Разумеется на бесплатный аккаунт распространяются определённые ограничения, но для разработчика-одиночки они некоторое время не действуют, так что ничто не мешает лично ознакомиться со всеми преимуществами сервиса. А другой альтернативой является AppVeyor. Они предлагают бесплатные учетные записи для всех проектов с открытым исходным кодом. Но здесь приложения iOS в целом, к сожалению, не поддерживаются.

Заключение

Как Вы можете видеть, в мире CI/DI происходит много всего и в распоряжении Microsoft теперь находится полный набор необходимых вещей для диагностики качества сборок Ваших приложений и выпуска их на суд широкой общественности. Я даже не успел ещё всего протестировать, но если Вы будете знакомиться с этой системой, не забудьте изучить Test Cloud, который также является мощным инструментом.

Если вы один из счастливчиков, понимающих голландский (нидерландский) язык, можете заглянуть на данный канал, который посвящен этому же самому предмету!

Любые вопросы можно направлять на мой почтовый ящик или Twitter (@jfversluis).

Благодарю Вас за внимание!

Автор: Gerald Versluis
Источник: Статья в блоге автора