О пользе DevOps и Xamarin.Forms для разработки бизнес-приложений [RUSSIAN]
•Download as PPTX, PDF•
0 likes•168 views
Презентация с нашего выступления на Developer Day 2017 Иваново “Кроссплатформенная разработка мобильных приложений”. Мы рассказали о процессе разработки мобильных приложений на базе Xamarin.Forms с использованием подхода Mobile DevOps
Recommended
Recommended
More Related Content
Similar to О пользе DevOps и Xamarin.Forms для разработки бизнес-приложений [RUSSIAN]
Similar to О пользе DevOps и Xamarin.Forms для разработки бизнес-приложений [RUSSIAN] (20)
О пользе DevOps и Xamarin.Forms для разработки бизнес-приложений [RUSSIAN]
- 1. О пользе DevOps и Xamarin.Forms для разработки бизнес-приложений Вячеслав Черников Руководитель отдела разработки, Binwell Ltd.
- 3. О компании Binwell Xamarin, Azure, DevOps Обо мне Qt, Mobile Web App, Native, Xamarin, архитектуры и процессы
- 4. О мире вокруг Critical Time-To-Market, Agile, DevOps everywhere IT rule them all Mobile First
- 7. Xamarin для разработки C#/.NET для всего Native iOS и Android Xamarin.Forms
- 8. Xamarin.Forms XF = UI virtualization + Helpers iOS, Android, Windows, Tizen OS, macOS
- 10. Xamarin.Forms развивается Особое внимание к производительности UI Требуется хороший опыт iOS, Android, Windows Многие компоненты надо писать самим
- 11. App, Navigation Service, Dialog Service, Pages, Controls, Views, Converters, Layouts ViewModels, Models = Data Objects, BL Services Data Services, Data ObjectsDAL BL UI Platform Service Interfaces, Settings Platform Services Native Renderers, Effects iOS/Android/Windows application, styles, resourcesBackend Архитектура XF-приложения
- 14. Пример карты переходов и состояний
- 15. Mobile DevOps
- 17. UI-тесты Автоматизация Use Cases Работоспособность на разных «модель+ОС» Проверка верстки
- 20. ДЕМО
- 21. О пользе DevOps и Xamarin.Forms для разработки бизнес- приложений Xamarin.Forms, Процесс разработки, Mobile DevOps Вячеслав Черников slava.chernikoff@binwell.com
Editor's Notes
- 1 минута. Представить, рассказать о том, что такие мероприятия очень важны и интересны. Выразить благодарность компании Akvelon и всем участникам.
- 2 минуты. В своем докладе я охвачу весть процесс разработки приложений на Xamarin.Forms, а не только особенности фреймворка, который является всего лишь инструментом в руках команды разработчиков. Отдельно рассмотрим то, как и зачем нужны практики DevOps в современной разработке мобильных приложений
- 4 минуты. В компании Binwell мы занимаемся разработкой мобильных и облачных приложений под заказ. Мы сфокусированы на стеке .NET и используем его для разработки мобильных и облачных приложений. Осуществляем разработку полного цикла и исходим из того, что продуктом нашей работы является не артефакт (билд или публикация), а процесс развития продукта с учетом бизнес-требований наших клиентов. Для разработки мобильных приложений мы используем Xamarin и в первую очередь Xamarin.Forms, так как этот фреймворк отлично ложится на наш процесс разработки и практики DevOps. Нам ближе всего по духу процесс OpenUP (облегченный Rational Unified Process), особое внимание уделяющий архитектуре. Облачные сервисы на базе Azure мы используем для автоматизации бизнес-процессов и построение Backend. Среди наших проектов: Интач Страхование, Инстамарт, Промсвязьбанк для физ. Лиц и другие. Мы активно развиваемся и делимся нашим опытом. Обо мне, с 2008 года занимаюсь кросс-платформенной разработкой мобильных приложений. Qt, Mobile Web, Native, Xamarin. Участвовал в более, чем в 40 мобильных проектах на базе различных технологических стеков. Мои статьи и материалы с выступлений доступны в канале Microsoft на Хабре, журнале Хакер и нашем Medium (ссылка на сайте компании).
- Начнем мы с высоты птичьего полета. С появлением глобальной сети очень сильно ускорился процесс обмена информацией, что в свою очередь начало трансформировать бизнес-процессы в компаниях. Критически важным становится скорость поставки ценности потребителями. А если проще – надо уметь быстро выпускать новые продукты и перерабатывать существующие, иногда даже - кардинально. Время, за которое выходят релизы с новой функциональностью называют обычно Time-To-Market и этот параметр становится очень важным для многих бизнесов. Для быстрой адаптации бизнес-процесс повсеместно внедряются гибкие и облегченные процессы с быстрым циклом обратной связи. Усиливается все это автоматизацией, чтобы рутинные и повторяющиеся операции выполняли железные дровосеки. Это привело к популяризации того, что сейчас называют Agile и DevOps, хотя элементы данных подходов существуют уже не один десяток лет. Как в свое время термин Облако изменил отношение к созданию серверных приложений, хотя само облако это просто виртуальное окружение, которое может масштабироваться и переноситься между железками по всему миру. IT продолжает трансформировать мир вокруг, является акселератором всех современных технологий, меняет бизнес и Mobile начинает играть в этом мире особую роль. Растут скорости передачи данных – появляются новые каналы и формы общения. Растут вычислительные мощности – появляются виртуальные миры и помощники. Мир IT ускоряется в первую очередь, поэтому нам как технарям тоже необходимо адаптироваться и использовать новые инструменты и подходы. И последним пунктом я хочу отметить важность мобильных приложений. Вы, наверняка, слышали, что недавно Android по количеству устройств обошел Windows. Персоналки и ноутбуки уходят из большинства рабочих мест, им на смену приходят мобильные устройства. Нужно больше приложений и нужны они будут быстро. При этот будут нужны будут как готовы коробочные, так и кастомные продукты различной сложности. В таком разрезе мне и хотелось бы посмотреть на кросс-платформенную разработку во время моего доклада.
- Начать я хочу с Xamarin.Forms, как с одного из перспективных фреймворков разработки мобильных приложений, завоевывающем все большую популярность и разделяющего философию сокращения параметра Time-To-Market.
- Все идет к тому, что для разработки бизнес-приложений в будущем будут использоваться 4 технологических стека: iOS+Swift, Android+Java, Xamarin и ReactNative. У каждого из стеков есть свои плюсы и минусы, которые необходим взвешивать перед стартом проекта. Но ключевым параметром на самом деле являются не возможности того или иного стека, а наличие компетенций и опытной команды, которая может учитывать все особенности и предложить решение в сложных ситуациях. Мы как технари обычно идем от стека, устраиваем холивары, хотя бизнес мыслит в логике рисков и бюджетов. Поэтому все чаще вопрос встает не о том, на чем вы пишете, а о том, какой результат и процесс вы можете предложить для решения задачи.
- Говоря о Xamarin cразу стоит отметить, что это в первую очередь название компании. А вот ключевых продуктов у компании в настоящий момент 3: Xamarin Classic (Xamarin.iOS и Xamarin.Android), Xamarin.Forms и Xamarin Test Cloud. Был еще сервис статистики, был куплен и потом закрыт фреймворк RoboVM (аналог Xamarin на Java), были игровые движки и своя версия Android. Xamarin Test Cloud - это облачная ферма устройств и к ней мы еще вернемся. То, что сейчас именуется как Xamarin Classic изначально называлось MonoTouch и MonoDroid. Как следует из названия – фрейворки основаны на проекте Mono и позволяют полноценно взаимодействовать с целевыми операционными системами с минимальными накладными расходами, использовать набор инструментов .NET и язык C#. На всякий случай уточню, что Xamarin создает полностью нативные мобильные приложения. Да, есть минимальный накладные расходы за счет конвертации вызовов и базовых структур данных, но они минимальны и на реальных проектах компенсируются ускорением в других местах. Классический Xamarin по возможностям близок к разработке на Swift и Java. Еще с ранних версий MonoTouch и MonoDroid энтузиастами предпринимались попытки логически продолжить начатое и предложить решения, которые были похожи на текущий Xamarin.Forms. Но решения были часто сырыми и ограниченными, поэтому до Xamarin.Forms все-таки приходилось реализовывать интерфейс отдельно для каждой платформы.
- После того, как классический Xamarin дозрел, собрал приличную армию разработчиков, был выпущен Xamarin.Forms, который и решает своего задачу «последней мили», предоставляя единый API для работы с пользовательских интерфейсом с минимальным вовлечением особенностей каждой из целевой платформы. При этом сам интерфейс остается полностью родным. То есть фактически XF это виртуализация пользовательского интерфейса и набор дополнительных подсистем вроде поддержки языка разметки XAML, общей шины событий и сервиса зависимостей. В настоящее время Xamarin.Forms официально поддерживает iOS, Android, Windows и в превью Tizen OS. Скоро добавят поддержку macOS, плюс есть проект по портированию XF на WPF.
- Для того, чтобы лучше понять, как работает XF, давайте рассмотрим простую кнопку. Одним из базовых механизмов являются рендереры, благодаря которым при отображении кнопки Xamarin.Forms фактически на экран добавляется нативный контрол, а свойства XF-кнопки динамически пробрасываются в свойства нативного контрола. По аналогии работают и все остальные контролы, обеспечивая полностью нативный пользовательский интерфейс на каждой целевой платформе. Стоит иметь в виду, что не все свойства контролов доступны в XF, поэтому часто приходится реализовывать свои простые рендереры.
- При создании приложений на Xamarin.Forms стоит уделять внимание производительности пользовательского интерфеса: особенности компоновщика внимание к ListView картинках FFImageLoading свои рендереры Для создания качественных пользовательских приложений все-таки нужен хороший опыт в платформах iOS, Android и Windows (при необходимости). Только специалистов таких потребуется гораздо меньше. Один Middle+ по каждой платформе может покрыть потребности в нескольких проектах. Также стоит учитывать, что Xamarin.Forms еще достаточно молодой фреймворк и несмотря на активную поддержку сообществом, все еще довольно часто требует создания своих собственных контролов и платформенных модулей. Плюс стоит учитывать, что для Xamarin Classic, на котором основан Xamarin.Forms, иногда приходится вручную подключать сторонние библиотеки и модули, что также потребует дополнительных усилий.
- Архитектура занимает ключевое место в реальных проектах, так как приложения необходимо не только написать, но и развивать дальше. Чем больше проблем с архитектурой, тем сложнее будет дальнейшее развитие проекта. В нашей практике мы используем многослойную архитектуру, где каждый модуль изолирован друг от друга и может быть вынесен в отдельный подпроект. DAL – уровень абстракции данных. BL – уровень бизнес-логики. UI – уровень пользовательского интерфейса.
- Сам по себе любой фреймворк это всего лишь инструмент, но его особенности должны учитываться с самых первых шагов проекта. Xamarin.Forms в данном случае не является исключением, поэтому дальше мы рассмотрим сам процесс разработки целиком.
- Существуют различные виды процессов разработки ПО, среди которых наибольшую популярность в силу их простоты приобрели Водопад и Итерационный/Спиральный. Из нашей практики, чистый Agile это штука очень дорогая и требовательная к квалификации всех участников процесса, включая клиента. Большинство игр в Agile или Scrum приводят к тому, что процесс затягивается до бесконечности, пока клиент ищет оптимальное решение, а команда постоянно переделывает проект. В нашей компании в настоящее время используется гибридный подход, когда на первых этапах проводиться полная детализация требований к проекту и при этом выдерживается баланс между информативностью и формализмом (количеством букв в ТЗ). Первым шагом мы составляем список функций (Feature Points) и общие требования к приложениям. Вторым шагом идет проектирование пользовательского интерфейса на уровне экранов (UX-прототип), когда используются только прямоугольники, иконки и текст. Это позволяет определить необходимую навигационную модель (например, нижние табы или боковое меню) и разбить функциональность и данные по экранам и блокам. В нашей практике мы используем сервис Proto.io, который за одно позволяет получить и интерактивный прототип прямо в телефоне. Главное – максимально просто, без дизайна. На основе UX-прототипа мы составляем карту переходов и состояний, о которой поговорим чуть далее. И уже на основе этой карты мы формализуем пользовательские сценарии, используемые при тестировании. После согласований и с клиентом мы составляем единое Частное техническое задание, включающее расширенное описание функциональности, схемы и описания экранов, а также карту переходов. После проектирования мы формируем верхнеуровневый беклог, который помимо самой функциональности также включает в себя разработку DAL и вспомогательных сервисов. На основе UX-прототипа мы готовим спецификации дизайна по каждому из экранов. Для того, чтобы было удобнее со всем этим работать в будущем, мы используем сквозное именование самих экранов и состояний, в которых они могут находиться. После этого уже подготавливается нарезка, необходимые иконочные шрифты и описываются спецификации и стили дизайна. Дальше начинается сама разработка, которую мы детализировать не будем, хотя и там тоже есть определенные закономерности и распараллеливание. На выходе из каждого цикла разработки появляются сборки, которые уходят в тестовую или реальную эксплуатацию (=публикация), во время которой собираются события, заводятся баги, анализируются креши и подготавливаются рекомендации по развитию продукта. Все это формирует новый пул задач и так на протяжении всего жизненного цикла продукта. Прошу обратить внимание, что наш процесс не имеет окончания, так как все продукты живут и развиваются. Остановка возможна только в случае форс-мажора или по соображениям бизнеса наших клиентов. Таким образом, продуктом нашей работы являются не артефакты (сборки, публикации), а рабочий процесс по формированию новых версий приложений и сервисов. Вот последний цикл как раз отлично ложиться на DevOps.
- Если вы занимались разработкой пользовательских интерфейсов сайтов или приложений, то вам доводилось видеть подход, когда все экраны чуть ли не в натуральную величину печатаются и стрелочками показываются взаимосвязи между ними. Это подход от дизайна и хорошо работает только в том случае, если у вас меньше 10 экранов. Однако бизнес-приложения обычно имеют гораздо сложнее и имеют от 20 до 100 экранов (бывают и больше, но это скорее исключение). Поэтому мы в своей работе пришли к показанному на схеме подходу, когда указываются только названия и ключевые состояния экранов, а также переходы между ними. Как видите, используя данную карту вы легко можете взять любые маршруты движения пользователя и выделить самые ключевые из них, для которых проект, собственно, и создается. Ведь цель приложения – решать проблемы или задачи пользователей, проводя его по определенным шагам. Для разработчика карта выступает в качестве своеобразного чек-листа. Плюс, используя архитектуру MVVM для Xamarin.Forms мы придерживаемся концепции «один экран – несколько состояний». Каждое из состояний – это отдельный набор интерфейсных элементов, сменой которых управляет ViewModel. Например, на показанной схеме четко видно, какие экраны загружают данные из сети и в каких состояниях они могут находиться. В реальных проектах карты на порядки сложнее, но их все равно можно распечатать на листе А4 и повесить над рабочим местом программиста, где он будет крестиками отмечать что сделано, а что нет. Теперь мы можем плавно перейти к описанию практик Mobile DevOps.
- Сам по себе DevOps это не просто набор инструментов, а культура и подход к разработке ПО, когда продуктом становятся не артефакты, а работающие процесс по созданию и развитию приложений. Mobile DevOps не исключение. И раз уж мы перешли в эпоху Mobile First, и DevOps у нас тоже должен быть мобильным.
- Напомню, что что главная задача DevOps – ускорение цикла выпуска продуктов (или их новых версий) за счет разумной автоматизации и непрерывного мониторинга. Это является критически важным для сокращения параметра Time-To-Market и внедрения гибких методик работы. На рисунке отражена упрощенная схема цикла выпуска продукта. Отдельно стоит отметить, что же из всего процесса разработки разумно автоматизировать. Явно, что пока невозможно адекватно автоматизировать процесс кодирования, так это очень сложная задача, требующая комплексных знаний и навыков. А вот сборку, публикацию, мониторинг и даже тестирование (с оговорками) автоматизировать очень легко, поэтому рынок сейчас переживает настоящий бум подобных сервисов. Из перечисленных выше работ самым интересным является процесс тестирования. И если с юнит-тестами все давно понятно и их умеет делать любая среда разработки, то вот тестирование пользовательского интерфейса является задачей посложнее.
- Что такое автоматизированн Яые UI-тесты, бывалые разработчики и тестировщики наверняка знают. Уже давно есть инструменты для тестирования десктопных приложений и сайтов. А вот автоматизированные UI-тесты для мобильных приложений появились совсем недавно. Компании Apple и Google представили специальные API для своих мобильных платформ, которые и позволяют имитировать работу пользователя на реальном (физическом) смартфоне или планшете. Для того, чтобы тестирование имело контролируемые и управляемые цели, описанные пользовательские сценарии (Use Cases) легко ложатся на специальные скрипты, вместо которых ранее приходилось тестировщикам руками тыкать в приложение для поиска ошибок на БОЛЬШОМ парке устройств. Одни и те же сценарии проверялись раз за разом на устройствах различных марок и производителей, разных версий операционных систем. Это колоссальный объем трудозатрат с учетом текущей фрагментированности рынка смартфонов и планшетов. Автоматизация позволяет заметно сократить подобные проверки. Сразу стоит сказать, что автоматизация не отменяет ручное тестирование, а просто уменьшает его объем. Приложения все равно должны тестироваться руками как самими разработчиками, так и специальными тестировщиками. Итак, что же дает автоматизированное UI-тестирование? Возможность проверить, что необходимая группа сценариев будет корректно работать на необходимом парке устройств и различных версиях операционных систем от различных производителей. Например, приложение может хорошо работать на Android 6.0, но падать на Android 5.0 или 4.1. Или на какой-то конкретной модели устройства. Подобные ошибки сразу будут вскрыты при автоматизированном тестировании. Написали один раз скрипт, а дальше оно само по вашей команде его запускает. Еще очень важным является проверка дизайна на разных размерах экранов и версиях операционных систем. Ничего не должно обрезаться или плыть. Все облачные фермы устройств делают скриншоты каждого шага для каждого устройства, поэтому о подобных проблемах с версткой вы также узнаете первым. Итак, какие же инструменты для DevOps подойдут разработчикам мобильных приложений?
- Если с репозиторием для кода все понятно, то вот систему сборки многие разработчики могут попробовать собрать у себя на коленке. Если вам нужны приключения, у вас есть шаманский бубен, борода и свитер – то это ваш путь Остальным же можно порекомендовать готовые решения. Одним из лучших и недорогих инструментов для сборки в настоящий момент является сервис Bitrise, поддерживающий все популярные стеки мобильной разработки, включая Xamarin и ReactNative. Например, кто-нибудь из команды отправил команду в мессендежер Slack (не важно кто!) и через несколько минут (ну или десяти минут для очень больших проектов) получил ссылку на установочный пакет с последним или указанным коммитом. Для автоматизированного UI-тестирования уже есть около десятка различных ферм, включая сервисы от Amazon и Google. Однако, Xamarin Test Cloud является одним из самых функциональных и удобных. Поэтому мы рекомендуем использовать именно его. Если UI-тесты прошли успешно, то приложение можно передавать для ручного тестирования. Для этого его можно загрузить в сервис HockeyApp, который по совместительству собирает статистику и крешы при работе приложений. Теперь цикл замыкается и есть понимание о качестве продукта. Стоит добавить, что Microsoft не так давно представила свой интегрированный конвейер DevOps на базе Xamarin Test Cloud и HockeyApp под названием Visual Studio Mobile Center. Он еще находится в стадии Preview и имеет существенные ограничения, но для знакомства вполне подходит. Подводя итог, приведем немного цифр.
- На слайде представлены средние показатели по нашим проектам, выполненным на базе Xamarin.Forms с использованием описанного DevOps-конвейра. Это типичные цифры от старта проекта до выпуска первой версии. 85% общего кода не включают в себя простые рендеры на уровне – пробросить дополнительное поле (например, рамочку) у стандартного контрола. 100+ различных смартфонов (связка модель+версия ОС), преимущественно на Android. Например, в Xamarin Test Cloud этот показатель имеет максимум около 250, просто все устройства дублируются по 4-6 экземпляров. 300+ сборок – в день может делаться по несколько, сборок для того, чтобы тестировщики могли погонять приложения руками или с помощью UI-тестов. В целом описанный подход не просто позволяет сэкономить время, но и заметно упростить процесс разработки, убирая рутину, а разработчикам оставляя только само кодирование. На этом все и я готов ответить на ваши вопросы.