Сегодня почти у каждого проекта мобильного приложения есть базовая инфраструктура: ваш код хранится на git хостинге и весь новый код регулярно проверяется на CI, чтобы не сломать старый. Если ваша команда в несколько человек производит не очень много кода, то скорее всего вы настроили весь пайплайн один раз и радуетесь его работе. Но что если ваша мобильная команда это пара десятков или даже сотен разработчиков? Много разработчиков производят много кода, что создает нагрузку на инфраструктуру, увеличивает вероятность сломать важные флоу приложения и просто навсего унести время сборки проекта в небеса. Единожды кем-то настроенный пайплайн обречен на изменения, если он не справляется с нагрузкой.
Вы уже наверное поняли о чем пойдет речь под катом? В виде интересной истории я расскажу вам про типичные проблемы мобильных команд (да-да, вы можете узнать в них свои), а также что такое Mobile DevOps, как он поможет решить проблемы и, наконец, как получить этот самый Mobile DevOps к вам в команду.
Mobile DevOps существует, даже если вы о нем не знаете
Говорить на тему DevOps особенно в направлении Mobile можно сколько угодно. Это тема богата на детали, обсуждения, вопросы, альтернативы и многое другое. Можно прочитать море определений понятия DevOps, попытаться интегрировать сюда мобильную разработку, но так до конца и не понять что же это такое. Поэтому я приготовил для вас небольшой рассказ, который поможет понять что это за зверь - Mobile DevOps. А после самого рассказа, в ходе которого вы сами найдете ответы на вопросы, я дам немного пояснений, который прольют еще больше света на эту интересную тему. Устраивайтесь поудобнее и наслаждайтесь рассказом.
Ах да, чуть не забыл, все имена и события в рассказе вымышлены, любые совпадения с реальными людьми и событиями случайны.
Представьте как выглядит обычный рабочий день Android разработчика Миши в компании Galera Development: Миша пришел в офис (или просто встал с кровати, ееее удаленка), приготовил себе чашечку кофе и сел за работу. Сегодня у него отличное настроение и работа обещает быть бодрой. Для разминки Миша берет задачу на простой фикс бага, быстро с ней справляется и создает пул реквест в develop. Остается дождаться успешной сборки на CI и пул реквест можно заливать. Миша на 200% уверен, что сборка пройдет успешно, ведь баг был прост, и он локально все проверил.
Но как оно иногда бывает - не все идет по плану. Сборка на пул реквест Миши почему-то не собралась. Наш герой подумал, что это какая-то разовая акция и перезапустил свою сборку. Проходит пара минут и Миша получает опять упавшую сборку. Что поделать, придется идти разбираться. Миша идет на CI в логи своей сборки и видит ошибку, которая совсем не похожа на те, что пишет Android Studio. “Что-то на эльфийском” - подумал он, но пул реквест заливать надо и надо как-то получить успешную сборку на CI. Миша слышал раньше, что настраивал CI его коллега Паша, и он наверняка должен знать как совладать с этим зверем.
Миша пишет Паше и рассказывает о проблеме. Проходит некоторое время и Паша отвечает “только не снова…” и просит еще раз перезапустить сборку и сообщить ему о результатах. Паша бы и рад пойти посмотреть в чем действительно дело, почему вдруг стабильно работающая система начала давать сбои, но он работает над фичей срок релиза у которой вчера, поэтому у него совсем на это нет времени.
У Миши уже настроение не настолько прекрасно как было утром, но он идет и перезапускает сборку. Через пару минут сборка действительно проходит, бодрый настрой и мотивация возвращаются к Мише, он заливает свой пул реквест и сообщает Паше, что сборка прошла и все в его жизни прекрасно. “Обошлось” - подумал Паша.
Проходит час, и на почту Паше пишут уже 5 разработчиков, которые тоже знают, что Паша маг и знает что происходит на CI. У них такая же история как и у Миши час назад - падают сборки. Что делать? Паша сейчас занят важной фичей, которая принесет компании несколько сотен миллионов в первую же неделю релиза. Еще один человек знает как устроен этот ваш зверь CI, но теперь он руководит небольшой командой IOS разработчиков в другой компании. Да и если Паше бросать свою работу над фичей и погружаться в проблему на CI, то на обнаружение проблемы и ее решение уйдет много времени, ведь Паша сам уже не помнит когда в последний раз заглядывал на CI и смутно помнит как там все устроено.
Паша решает сообщить о возникшей ситуации своему руководителю Антону. Так как надо много чего обсудить, они договариваются на созвон.
Антон: Привет! Ну как там с билдами?
Паша: Привет! Все плохо, я посмотрел логи, но сразу ничего не могу сказать, надо садиться и разбираться, но у меня на это совсем нет времени. Я занят сам знаешь какой фичей и мне не вариант откладывать работу по ней.
Антон: А еще не вариант тормозить всю разработку проблемой на CI! Предлагаю следующее: ты сейчас разбираешься с проблемой на CI, а я подключаю к тебе на разработку фичи еще 2 разработчиков, годится?
Паша: Другого варианта не вижу, так и поступим.
Антон: Отлично, тогда подключу к тебе на помощь Костю и Артема. Свяжусь с ребятами и проинформирую их, что у них теперь новая задача. Как закончишь работы на CI, напиши им.
Паша не очень любит такие резкие переходы по задачам, да еще в и так стрессовой ситуации приближающегося релиза. Он закоммитил то что у него уже готово по этой задаче и надеется, что Костя с Артемом правильно поймут спроектированное решение и качественно его реализуют.
И вот наш герой пошел смотреть логи упавших билдов, но их уже стало на пару десятков больше с того момента как ему написали 5 его коллег. Дело похоже действительно плохо. Когда полгода не приходилось плотно сидеть за инструментом - начинаешь забывать как он устроен и что у него может пойти не так. Паша с трудом, парой часов просмотра логов и гуглением из них строк понимает, что ресурсы, используемые CI для сборок, уже недостаточны, и поэтому возникают проблемы.
Когда он полгода назад поднимал эти ресурсы для команды мобильной разработки все летало, и команда на руках его носила за проделанную работу. Паша пытается понять причину упора в потолок по ресурсам, что такого произошло, что именно сегодня начали всплывать такие проблемы. Все оказалось просто: за последние 2 месяца в команду мобильной разработки пришло пара десятков новых разработчиков. Разумеется, команда стала писать больше кода, который надо собирать на CI, что и дало нагрузку, пик которой пришелся на сегодня. Вот это денек! Паша прикинул сколько ресурсов дополнительно потребуется и создал заявку на ресурсы администраторам серверов.
А еще Паша заметил, что время сборки проекта стало в 4 раза больше! Он когда-то для проекта занимался оптимизацией времени, но сделал лишь часть от того что знал и планировал, очередные горячие фичи были приоритетнее. Паша тогда сделал лишь те оптимизации, которые существенно ускоряют сборку, а те, что ускоряют не сильно, или будут ускорять, только если проект будет намного больше - не сделал. Об этом он сейчас вспомнил и отметил себе, чтобы рассказать Антону. Так и подошел конец рабочего дня. Паша звонит Антону и рассказывает об успехах.
А вы тоже уже на этом моменте подумали как будет затратно компании если Паша уйдет?
Антон: Как успехи?
Паша: Я разобрался с причиной: мы уперлись в потолок по ресурсам. Я уже завел заявку админам, скоро нам должны выделить еще немного ресурсов, что стабилизирует сборки.
Антон: Круто! Спасибо тебе, выручил. Теперь можешь спокойно возвращаться к работе над своей фичей.
Паша: На самом деле есть еще кое-что. Я посмотрел как изменилось время сборки в последнее время - оно сильно выросло. Теперь вместо прежних 10 минут это 45 минут. Я думаю с этим надо что-то делать.
Антон: Ну и кода у нас стало больше. Скорее всего это закономерно.
Паша: Не соглашусь с тобой. У нас есть еще большой задел для оптимизации. Я могу провести ряд работ, но это займет некоторое время, чтобы провести оптимизации и протестировать их работу.
Антон: Даже если ты сейчас вернешься к работе над нашей фичей, то после нее тебя ждет другая, у нас очень много работы. Боюсь, оптимизацию придется отложить. Есть возражения?
Паша: Да. Сейчас расскажу почему. У нас работает 50 Android разработчиков, которые собирают свои пул реквесты на CI да и локально тоже, но сейчас не об этом. Сейчас сборка занимает примерно 45 минут. Я не говорю, что смогу ее ускорить до 10 прежних минут. Но проходить минут за 30 она точно будет, а в некоторых случаях и быстрее. То есть я предлагаю сэкономить на каждой сборке по 15 минут. В среднем разработчик собирает на CI по 2 пул реквеста в день. Это 0.5 часа в день экономии времени разработчика на ожидание сборки на CI и 0.5 часа занимаемых ресурсов. Ладно, отложим в сторону ресурсы и сосредоточимся на времени разработчиков: у нас 50 разработчиков, которые могут в день экономить по полчаса своего времени, то есть за месяц вся команда Android разработки сэкономит 50 разработчиков * 20 рабочих дней * 0.5 часа экономии = 500 часов разработки. Планирую я на это дело потратить примерно месяц, то есть 160 часов. Как видишь, заняться оптимизацией сейчас это просто отличная возможность сэкономить 500 часов Android разработки каждый месяц. Неплохо, не правда ли? Плюс, я могу покопаться со сборкой IOS проекта, думаю, там тоже есть большой задел для оптимизаций.
Антон: Ты заставил меня задуматься над этим. Давай я все обдумаю и созвонимся завтра. Решим что делать.
Паша: Договорились. До завтра.
Антон: Пока.
После рабочего дня у Паши двойственные чувства. С одной стороны немного досадно, что пришлось отдать работу над фичей Косте и Артему и завтра скорее всего он к ней тоже не вернется. Но с другой стороны сегодня ему удалось позаниматься и решить проблемы всей мобильной команды. Он вылечил головную боль десятков классных ребят и очень рад этому. Приятно видеть каждый день людей, которым помогаешь. Плюс такие задачи могут немного разнообразить твои текущие задачи и дают понимание, что ты делаешь нечто особенное, что под силу далеко не всем, а в твоем случае только тебе в команде.
Наступает следующий день. Паша садится с кружкой кофе (но уже покрепче в 2 раза чем вчера) и начинает смотреть почту. В целом ничего интересного: поставили на ревью, накинули замечаний в его пул реквест с небольшим баг фиксом, уведомление об обновлении версии CI завтра, корпоративные новости, день рождение коллеги… Погоди, что? Обновление версии CI завтра?! Паша понял, что без внимания этот момент оставить нельзя. Совсем неизвестно как это повлияет на его текущую конфигурацию, которая теперь более менее стабильно собирает проект, а еще не известно как повлияет на интеграцию CI с другими сервисами инфраструктуры. Похоже придется провести ряд проверок, которые займут неизвестно сколько времени, а обновление уже завтра. Вот и еще одна тема для обсуждения с Антоном.
Антон: Доброе утро! Я тут все обдумал, и, кажется, ты прав, нам стоит провести ряд оптимизаций.
Паша: Привет! Это отличная новость. Когда приступать?
Антон: Можешь приступать прямо сейчас. И еще один момент, в связи с тем, что мы в последнее время довольно часто подходим к релизу со сломанными основными сценариями, которые находят, слава Богу, тестировщики, а не пользователи, то мы решили завозить в проект UI тесты, чтобы мы были уверены, что новые фичи не ломают наши основные сценарии. Прогнали UI тесты - сразу убедились, что основные сценарии целы, круто, правда? И поэтому надо научить наш CI прогонять эти UI тесты. Я пока без малейшего понятия как это реализовать, поэтому в первую очередь говорю об этом тебе. Было бы здорово, если бы ты занялся этой инфраструктурной задачей.
Паша: Неожиданно. Задача звучит очень непонятной и сложной, но мне в целом было бы интересно ей заняться. Надеюсь ты понимаешь, что это задача не на неделю и даже не на месяц, если я ее беру, то скорее всего полностью выпадаю из продуктовых Android задач.
Антон: Да, конечно. Более того, я подумал над всеми этими задачами, заглянул в наш бэклог и нашел еще несколько задач на оптимизацию наших процессов, которые могут тоже неплохо сэкономить нам ресурсы разработчиков. Я прикинул, затраты на выполнение этих инфраструктурных задач окупятся даже в ближайший квартал! Плюс, я планирую обсудить задачи такого типа еще и с IOS командой, у них наверняка тоже что-то есть. Поэтому я сделал запрос на найм к нам в команду еще одного инженера, который бы помог организовать работу нашей инфраструктуры. В общем решили искать Mobile DevOps инженера, если можно так выразиться конечно. Будем надеяться что получится найти такого, хоть и на рынке Mobile DevOps инженеров единицы. Ну а пока ты ответственный за работу нашей инфраструктуры, можешь довести до конца свои текущие Android задачи и заняться инфраструктурой. Если все-таки не получится нанять Mobile DevOps a, то тебе нужно будет взять кого-то к себе в команду, кто хотел бы заниматься инфраструктурой и ввести в курс дела. Что скажешь насчет всего этого?
Паша: Звучит здорово. Я в деле. При таком раскладе у меня есть срочная инфраструктурная задача: от админов пришло письмо, в котором сообщается об обновлении нашего CI, надо срочно проверить что в новой версии все будет работать по прежнему и всякие интеграции тоже. Планирую ей сейчас заняться.
Антон: Спасибо, что заметил это письмо и понял чем оно может для нас обернуться. Тогда не буду тебя отвлекать. О деталях твоих новых рабочих процессов поговорим позже. Поздравляю, теперь ты Mobile DevOps, ахахаха!
Паша: Договорились. Спасибо! Хорошего дня!
Антон: Спасибо, и тебе!
И Паша отправился непростой и интересной дорогой Mobile DevOps инженера!
Что я только что прочитал?
Надеюсь, я справился со своей задачей, прочитав этот небольшой рассказ вы нашли в нем ответы на вопросы:
Что такое Mobile DevOps?
Какие проблемы Mobile DevOps решает?
Как Mobile DevOps решает проблемы?
Как получить Mobile DevOps инженера в команду?
Как стать Mobile DevOps инженером?
Но я все-таки отвечу на каждый вопрос более развернуто. То что вы прочитали должно дать плотный фундамент для понимания темы Mobile DevOps и этих вопросов конкретно.
Что такое Mobile DevOps?
Здесь я не скажу ничего особо отличающегося от понятия классического DevOps. Это все так же Development и Operations, но в области мобильной разработки. Инженер, занимающийся Mobile DevOps, занимается не только разработкой и поддержкой инфраструктуры (как мы увидели в рассказе мага Пашу, который умел колдовать на CI, оптимизировать сборку с помощью магического Gradle и многое другое), но и совершенствованием процессов мобильных команд (когда Паша начал продумывать как проверять UI тесты для нового кода коллег, чтобы не сломать существующий код).
Про первую часть Development вам всегда будет напоминать огромный список задач в бэклоге, про нее вы никогда не забудете. А вот про вторую часть действительно стоит помнить. Главная цель нашего Mobile DevOps - обеспечивать команде эффективную и комфортную работу. Мы должны прислушиваться к команде, слушать когда они говорят о своих болях и пытаться их решить инструментами, которые мы можем даже пока и не знать.
Mobile DevOps инженер должен хорошо знать как работает команда, понимать процессы и видеть уязвимые места, которые стоит усилить. Чтобы всегда быть в курсе процессов, возможно, не помешает участие в общих ретроспективах, чтобы не упустить какое-то важное изменение в процессах команды или услышать обратную связь по текущим процессам.
Какие проблемы Mobile DevOps решает?
Как я уже ответил в предыдущем вопросе: Mobile DevOps должен решать проблемы в инфраструктуре команды и процессах. Но так как мы ограничили область DevOps мобильной разработкой, то предлагаю конкретизировать проблемы, которые может решать Mobile DevOps.
CI. Создание CI сервера, его конфигурирование, общение с админами по поводу обеспечения сервера ресурсами. Настройка сборок для всех проектов команды.
Оптимизация сборок. Конфигурирование системы сборки (например, Gradle для Android) проекта для обеспечения наилучшего времени сборки как локально, так и на CI. Обеспечение эффективного использования кэша сборки.
Автоматические проверки кода. Это могут быть простые тулзы-анализаторы код стайла типа Sonar или Detekt, а может что-то посложнее и самописное в виде Gradle тасок, например, таска для проверки соответствия правилам зависимостей проекта.
Прогон UI тестов на CI. Обеспечение работы набора устройств или эмуляторов и обеспечение возможности прогона на них UI тестов.
Impact analysis. Анализ измененного кода для получения списка затронутых UI тестов, которые надо прогнать, чтобы убедиться, что в новом коде разработчик не сломал старый.
Интеграция сервисов инфраструктуры. Обеспечение стабильной интеграции сервисов инфраструктуры типа CI, git-хостинга кода и других сервисов.
Release Train. Автоматизация процесса релиза вплоть до автоматического деплоя бандла в Play Console и раскатки его в продакшн.
Это я привел лишь основные направления, по которым требуются усовершенствования для любой крупной команды. Но у каждой команды есть свои особенности в процессах, из-за которых может появиться еще больше направлений для работы Mobile DevOps инженера.
Как Mobile DevOps решает проблемы?
Тут все по классике: чтобы решить проблему ее нужно понять. Как я уже говорил ранее - понимание процессов команды невероятно важно в работе Mobile DevOps инженера. Это поможет выявить слабые места в процессах и усилить их.
После того как удалось определить проблему нужно заняться проектированием решения. Хочу заметить, что в первую очередь нужно именно спроектировать решение, составить план, сценарий, который будет решать проблему, а не заниматься сначала выбором инструмента решения. Ведь хорошо спроектированное решение позволит вам ничего не упустить при реализации и выбрать лучший инструмент, с помощью которого вы решите проблему с минимальными затратами.
Вот примеры инструментов, с помощью которых можно решить инфраструктурные и процессные проблемы:
Gradle таски, которые будут выполняться в нужный момент (для Android)
Gradle плагины (для Android)
Скрипты, которые могут выполняться как вручную, так и автоматически, например, на CI
Шаги сборки на CI, которые могут выполнять абсолютно разные действия
Создание клиент-серверных приложений на различном стеке технологий
Контейнеризация для изоляции ваших сервисов, автоматизации их развертки и конфигурирования
Виртуализация для работы с эмуляторами
Создание плагинов для любого из сервисов вашей инфраструктуры, если есть открытое API
И это только примеры. Разумеется, инструменты могут быть невероятно различными.
Как получить Mobile DevOps инженера в команду?
Как вы уже поняли по рассказу, вероятно, у вас уже есть человек, который знает как работает ваша инфраструктура, он умеет решать какие-то критические проблемы. Если он имеет желание заниматься инфраструктурой и процессами вашей команды, то вам повезло и у вас есть Mobile DevOps инженер, который готов решить ваши боли.
Но хочу отметить, что ваш новоиспеченный Mobile Devops только вчера занимался парсингом jsonа и передвигал кнопки, поэтому не стоит требовать решения проблем в совсем ближайшее время. Специфика работы и инструменты решения проблем Mobile DevOps сильно отличается от Android или IOS разработки, и развитие вашего инженера будет постепенным. Через какое-то время (это может быть полгода, год, все очень ситуативно) ваш инженер будет действительно способен решать ваши проблемы быстро и качественно. И вы будете счастливы и горды, что в вашей команде есть такой специалист.
Но также есть альтернатива, которая довольно привлекательна. Мы живем в такое время, когда все технологии и процессы развиваются стремительно и есть компании, которые уже активно практикуют Mobile DevOps. Их инженеры уже решили много проблем и имеют большой опыт в практике DevOps в направлении мобильной разработки. Это все те же люди, которые постоянно развиваются и ищут новые возможности, поэтому можно попытать удачу и поискать такого инженера в сервисах для поиска работы. Разумеется найти инженера с таким уникальным опытом намного сложнее, чем Android разработчика или IOS разработчика, но они тоже люди и бывают открыты предложениям.
Сколько нужно Mobile DevOps инженеров?
На самом деле все зависит от объема работы и от результата, которого вы хотите достигнуть с помощью Mobile DevOps. Разумеется, чем больше инженеров вы выделите, тем быстрее будут развиваться ваша инфраструктура и процессы. Но даже если вы не располагаете большими ресурсами, то стоит выделить хотя бы 2 Mobile DevOps инженеров. Если у вас один инженер, то когда он уйдет в отпуск, на больничный или в другую компанию - ваша инфраструктура при возникновении проблем будет парализована, и вся разработка может просто заблокироваться на неопределенный срок. Поэтому не стоит складывать все яйца в одну корзину и стоит подумать о рисках.
А почему бы просто не привлечь настоящего DevOps?
Как я уже говорил ранее, DevOps это не только про инфраструктуру, но и про процессы. Человек, который варился много времени в процессах Android или IOS команд, хорошо понимает специфику работы и отлично понимает боли команд, потому что сам их скорее всего испытывал. Да, он пока не так хорош в инфраструктуре, как обычный DevOps, но все это можно изучить и наверстать. Сам опыт процессов невероятно важен и если вы получите к себе в команду Mobile DevOps (обучите своего или, если повезет, найдете на рынке), то станете действительно богаты в плане ресурсов инженеров.
Что делать, если вы хотите стать Mobile DevOps инженером?
Инициатива зачастую наказуема. Поэтому если вы видите проблемы в вашей инфраструктуре или в процессах команды, то обязательно расскажите об этом вашему лиду или руководителю, как это сделал Паша. Предложите ваше решение и я более чем уверен, что руководство вам не откажет. Ведь им интересно, чтобы команда работала эффективнее и выполняла больше работы. Все как всегда в ваших руках!
Заключение
Спасибо вам, дорогие читатели за внимание! Надеюсь, прочитав статью, вы получили все полезные знания, которые я постарался вложить в нее. А также приобрели мотивацию задуматься о ваших процессах и о концепции Mobile DevOps для ваших команд. Если мне все это удалось, то я очень рад, что смог вам помочь найти путь джедая Mobile DevOps!
Естественно, я приглашаю вас обсудить возникшие в ходе прочтения статьи вопросы в комментарии.
