Привет, Хабр! Сегодня мы делимся с вами простым и понятным руководством по тому, как применять Mobile DevOps на практике. Помимо бумажного руководства, под катом вы также сможете найти видео-записи одноименного мастер-класса, где рассмотрен каждый аспект DevOps применительно к мобильной разработке.
Передаю слово автору, Вячеславу Черникову.
Приветствую тебя, читатель. Лето в очередной раз пролетело со скоростью кометы, и вместе с осенью приходит пора возвращаться к 150% продуктивности. Еще весной мы с Microsoft подготовили руководство “Mobile DevOps на практике” о том, как можно по максимуму автоматизировать процесс разработки мобильных приложений. Ниже приведен ознакомительный фрагмент из полного руководства.
Сам по себе DevOps медленно шагает по планете в обнимку с гибкими методиками управления. Однако если присмотреться поглубже, то DevOps это в первую очередь культура, в которой вся команда, развивающая и обслуживающая ИТ-систему, работает как одно целое. Именно общение внутри команды является обязательным для выстраивания здорового взаимодействия между бизнесом, программистами, сисадминами и тестировщиками.
Вторым важным элементов любого DevOps-процесса является обучение команды. В идеальном мире команда (начиная с бизнеса) должна учиться все лучше удовлетворять нужды конечного пользователя, создавая ценность для потребителя. Но на практике еще и «ценность» надо научиться считать и делать из этого грамотные выводы. Для обучения в любом случае необходима обратная связь от реальных пользователей. Такой связью становятся системы непрерывного мониторинга жизнеспособности ИТ-систем и разнообразные системы логирования.
И что бы этот DevOps существовал не только в головах у разработчиков, то его необходимо реализовать на практике с помощью инструментов, которые подойдут под нужды задачи. Частью DevOps-культуры также является стремление к автоматизации рутинных действий. Это делает процесс разработки и развития ИТ-систем менее болезненным и более эффективным.
Сам по себе DevOps появился как подход для больших команд и компаний, работающих над крупными ИТ-системами, состоящими из большого числа модулей, часто написанных на разных языках программирования и предназначенных для разных сред выполнения. Однако по мере популяризации термина и подхода, DevOps стал адаптироваться различными командами, решающих широкий спектр задач.
Чаще всего DevOps ассоциируется с крупными цифровыми продуктами, разработкой и обслуживанием которых занимаются десятки, сотни, а иногда и тысячи специалистов. У многих команд уже выработались свои практики и свои инструменты для поддержания процесса DevOps — системы автоматической сборки, тестирования, развертывания и мониторинга. Обычно это все создается на собственной инфраструктуре, но активно развиваются и облачные инструменты CI/CD.
Рисунок 1. Отличие Mobile DevOps от Enterprise DevOps
Все это мало ассоциируется с разработкой мобильных приложений. Mobile DevOps является «уменьшенной» версией обычного DevOps, так как мобильные приложения это в первую очередь удобный интерфейс для взаимодействия с внешними ИТ-системами. Меньший масштаб команды, и свои специфические проблемы, характерные именно для мобильных приложений (см. рисунок 1):
Для того, чтобы DevOps работал и между командами было реальное взаимодействие, необходим единый язык и единая рабочая документации, понятная всем участникам. Здесь четких руководств ни один подход не дает, да и системы все разные. Однако именно документация живет с проектом полный жизненный цикл и является инструментом для общения и взаимодействия команды.
Рисунок 2. Рабочая документация
Грамотная рабочая документация способна упростить и ускорить развитие проекта. Подробнее данный процесс описан в нашем Guide #2 "Техническое проектирование мобильных приложений".
Здесь же мы обозначим основные документы (см. рисунок 2):
— список экранов;
— карта переходов и состояний;
— таблица экранов.
Важным является использование в этих документах сквозного именования и нумерации. Именно это упрощает и ускоряет процесс общения внутри команды. Также важным фактором является соответствие “документация-код”, что делает понятным общение бизнеса с разработчиками.
Итак, с культурой взаимодействия и рабочей документацией мы определились и теперь можно переходить к инструментальной поддержке в виде CI/CD-конвейера. Чем больше операций получится автоматизировать, тем лучше.
У мобильной разработки есть 3 отличительных проблемных места:
В общем, без тестирования и отладки на большом парке реальных устройств не обойтись.
В реальной практике невозможно обойтись без ручного тестирования на смартфонах или планшетах. Однако часть кода легко покрывается автоматическими тестами на базе Unit Testing (далее просто unit-тесты). Давайте рассмотрим типовую архитектуру большинства приложений — рисунок 3.
Рисунок 3. Классическая трехзвенная архитектура
Полное покрытием тестами разумнее разумнее осуществлять по 2 направлениям:
Покрывать все unit-тестами в мобильных приложениях не представляется возможным, плюс это снижает скорость разработки и обновления системы. Для этапа автоматического unit-тестирования в рамках CI/CD-конвейера будет полезным покрыть следующие механизмы слоя DAL:
Если говорить об автоматических UI-тестах, то можно протестировать следующее:
По результатам UI-тестов собираются скриншоты с каждым шагом на каждом устройстве, на их основе QA-инженер в ручном режиме может просмотреть правильность верстки приложения на разных разрешениях и размерах экранов.
Удобство, плавность анимаций и другие пользовательские характеристики сложно отдать на откуп автотестам, их лучше оставить живым тестировщикам и бета-пользователям.
Конец ознакомительного фрагмента.
Полная цифровая версия бумажного руководства “Mobile DevOps на практике”.
Хочется обсудить Mobile DevOps вживую или задать вопросы — буду рад тебя видеть на Microsoft DevOps Summit 13 сентября в Москве (регистрация) или на DevOps Days 14-15 сентября в Казани (подробнее).
Как всегда, буду благодарен за обратную связь и вопросы в комментариях! Оставайтесь на связи!
Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone.
Статьи Вячеслава вы также можете прочитать в блоге на Medium.
Передаю слово автору, Вячеславу Черникову.
Mobile DevOps: руководство к действию
Приветствую тебя, читатель. Лето в очередной раз пролетело со скоростью кометы, и вместе с осенью приходит пора возвращаться к 150% продуктивности. Еще весной мы с Microsoft подготовили руководство “Mobile DevOps на практике” о том, как можно по максимуму автоматизировать процесс разработки мобильных приложений. Ниже приведен ознакомительный фрагмент из полного руководства.
1. Про DevOps
1.1 О культуре DevOps
Сам по себе DevOps медленно шагает по планете в обнимку с гибкими методиками управления. Однако если присмотреться поглубже, то DevOps это в первую очередь культура, в которой вся команда, развивающая и обслуживающая ИТ-систему, работает как одно целое. Именно общение внутри команды является обязательным для выстраивания здорового взаимодействия между бизнесом, программистами, сисадминами и тестировщиками.
Вторым важным элементов любого DevOps-процесса является обучение команды. В идеальном мире команда (начиная с бизнеса) должна учиться все лучше удовлетворять нужды конечного пользователя, создавая ценность для потребителя. Но на практике еще и «ценность» надо научиться считать и делать из этого грамотные выводы. Для обучения в любом случае необходима обратная связь от реальных пользователей. Такой связью становятся системы непрерывного мониторинга жизнеспособности ИТ-систем и разнообразные системы логирования.
И что бы этот DevOps существовал не только в головах у разработчиков, то его необходимо реализовать на практике с помощью инструментов, которые подойдут под нужды задачи. Частью DevOps-культуры также является стремление к автоматизации рутинных действий. Это делает процесс разработки и развития ИТ-систем менее болезненным и более эффективным.
1.2 В чем разница DevOps vs Mobile DevOps
Сам по себе DevOps появился как подход для больших команд и компаний, работающих над крупными ИТ-системами, состоящими из большого числа модулей, часто написанных на разных языках программирования и предназначенных для разных сред выполнения. Однако по мере популяризации термина и подхода, DevOps стал адаптироваться различными командами, решающих широкий спектр задач.
Чаще всего DevOps ассоциируется с крупными цифровыми продуктами, разработкой и обслуживанием которых занимаются десятки, сотни, а иногда и тысячи специалистов. У многих команд уже выработались свои практики и свои инструменты для поддержания процесса DevOps — системы автоматической сборки, тестирования, развертывания и мониторинга. Обычно это все создается на собственной инфраструктуре, но активно развиваются и облачные инструменты CI/CD.
Рисунок 1. Отличие Mobile DevOps от Enterprise DevOps
Все это мало ассоциируется с разработкой мобильных приложений. Mobile DevOps является «уменьшенной» версией обычного DevOps, так как мобильные приложения это в первую очередь удобный интерфейс для взаимодействия с внешними ИТ-системами. Меньший масштаб команды, и свои специфические проблемы, характерные именно для мобильных приложений (см. рисунок 1):
- — различные платформы;
- — различные устройства.
1.3 Единая документация и единый язык
Для того, чтобы DevOps работал и между командами было реальное взаимодействие, необходим единый язык и единая рабочая документации, понятная всем участникам. Здесь четких руководств ни один подход не дает, да и системы все разные. Однако именно документация живет с проектом полный жизненный цикл и является инструментом для общения и взаимодействия команды.
Рисунок 2. Рабочая документация
Грамотная рабочая документация способна упростить и ускорить развитие проекта. Подробнее данный процесс описан в нашем Guide #2 "Техническое проектирование мобильных приложений".
Здесь же мы обозначим основные документы (см. рисунок 2):
— список экранов;
— карта переходов и состояний;
— таблица экранов.
Важным является использование в этих документах сквозного именования и нумерации. Именно это упрощает и ускоряет процесс общения внутри команды. Также важным фактором является соответствие “документация-код”, что делает понятным общение бизнеса с разработчиками.
2. Особенности Mobile CI/CD
Итак, с культурой взаимодействия и рабочей документацией мы определились и теперь можно переходить к инструментальной поддержке в виде CI/CD-конвейера. Чем больше операций получится автоматизировать, тем лучше.
2.1 Проблемы Mobile Dev
У мобильной разработки есть 3 отличительных проблемных места:
- Различные операционные системы и их версии. Приложение должно корректно работать на широком спектре самых различных ОС, каждая из которых имеет свои особенности и ограничения.
- Различные варианты архитектуры центрального процессора. Железо смартфонов и планшетов постоянно улучшается, однако не надо забывать и о “старичках” пятилетней давности, которые могут быть на руках у ваших реальных пользователей.
- Различные разрешения экранов устройств. Независимо от количества пикселей или соотношения сторон, интерфейс мобильного приложения должен корректно отображаться на всех устройствах.
В общем, без тестирования и отладки на большом парке реальных устройств не обойтись.
2.2 Что можно тестировать автоматически
В реальной практике невозможно обойтись без ручного тестирования на смартфонах или планшетах. Однако часть кода легко покрывается автоматическими тестами на базе Unit Testing (далее просто unit-тесты). Давайте рассмотрим типовую архитектуру большинства приложений — рисунок 3.
Рисунок 3. Классическая трехзвенная архитектура
Полное покрытием тестами разумнее разумнее осуществлять по 2 направлениям:
- unit-тесты (функциональные, интеграционные) для слоя доступа к данным (Data Access Layer) или Repositories.
- UI-тесты (функциональные, регрессионные) для слоев Business Logic и User Interface.
Покрывать все unit-тестами в мобильных приложениях не представляется возможным, плюс это снижает скорость разработки и обновления системы. Для этапа автоматического unit-тестирования в рамках CI/CD-конвейера будет полезным покрыть следующие механизмы слоя DAL:
- методы доступа к Backend API;
- методы доступа к данным (Repositories);
Если говорить об автоматических UI-тестах, то можно протестировать следующее:
- работоспособность приложения на реальных устройствах с нужными характеристиками;
- возможность выполнить ключевые бизнес-сценарии.
По результатам UI-тестов собираются скриншоты с каждым шагом на каждом устройстве, на их основе QA-инженер в ручном режиме может просмотреть правильность верстки приложения на разных разрешениях и размерах экранов.
Удобство, плавность анимаций и другие пользовательские характеристики сложно отдать на откуп автотестам, их лучше оставить живым тестировщикам и бета-пользователям.
Конец ознакомительного фрагмента.
Полезные материалы
Книга Mobile DevOps на практике
Полная цифровая версия бумажного руководства “Mobile DevOps на практике”.
Видео-материалы мастер-класса “Mobile DevOps на практике” (4 части на 3,5 часа)
Часть 1
Часть 2
Часть 3
Часть 4
DevOps Summit
Хочется обсудить Mobile DevOps вживую или задать вопросы — буду рад тебя видеть на Microsoft DevOps Summit 13 сентября в Москве (регистрация) или на DevOps Days 14-15 сентября в Казани (подробнее).
Как всегда, буду благодарен за обратную связь и вопросы в комментариях! Оставайтесь на связи!
Об авторе
Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.
