Infrastructure as code

Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.




В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

Предыстория: параллельные миры разработчиков и инфраструктуры

Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать через забор к команде инфраструктуры.

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

Этот культурный и технологический разрыв вызывает не только недоумение, но и проблемы: на стыке разработки, инфраструктуры и бизнеса. С частью проблем в инфраструктуре сложно бороться из-за близости к железу и относительно слабо развитых инструментов. Но остальное вполне можно победить, если начать смотреть на все свои Ansible-плейбуки и Bash-скрипты как на полноценный программный продукт и применять к ним те же требования.

Бермудский треугольник проблем

Однако я начну издалека с проблем, ради которых все эти пляски нужны.

Проблемы разработчиков

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

• собрали классную команду;
• за полгода написали удобное и красивое приложение;
• подкрепили торжественный запуск вкусными промоакциями;
• и в первый же день благополучно упали под нагрузкой.

Косяков на старте было, конечно, много, но больше всего мне запомнился один. На время разработки на продакшене был развёрнут один слабый сервер, почти калькулятор, который обрабатывал запросы с приложения. Перед публичным анонсом приложения его нужно было увеличить мы живем в Azure, и это решалось нажатием одной кнопки.

Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном некритичного сервиса обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:

Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.

Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOpsами/SRE. В итоге программисты:

Зависят от команды инфраструктуры. Это вызывает боль, недопонимание, иногда взаимную ненависть.

Проектируют свои системы в отрыве от реальности и не учитывают, где и как будет выполняться их код. Например, архитектура и дизайн системы, которая разрабатывается для жизни в облаке, будет отличаться от дизайна системы, которая хостится on-premise.

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

Не могут оптимизировать деньги и другие ресурсы компании, которые используются для поддержания их кода. По нашему опыту бывает так, что команда инфраструктуры просто заливает проблему деньгами, например, увеличивая размер сервера БД на продакшене. Поэтому часто проблемы кода даже не доходят до программистов. Просто почему-то инфраструктура начинает стоить дороже.

Проблемы инфраструктуры

Сложности есть и на другой стороне.

Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

• 60 ролей;
• 102 плейбука;
• обвязка на Python и Bash;
• тесты в Vagrant, запускаемые вручную.

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

Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или некогда запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.

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

Проблемы бизнеса

У бизнеса тоже есть две большие проблемы, которые нужно решать.

Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, подсчитать невозможно, в деньгах это не оценивается.

Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:

• с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
• с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
• с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?

Как решить все эти проблемы? Решение мы нашли в книге Site Reliability Engineering от Google. Когда прочли, поняли это то, что нам нужно.

Но есть нюанс чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

Из хороших практик SRE у нас уже были:

• механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
• процессы для дежурств 24/7 on-call;
• практика ведения постмортемов по инцидентам и их анализ;
• нагрузочное тестирование;
• CI/CD-пайплайны для прикладного софта;
• хорошие программисты, которые пишут хороший код;
• евангелист SRE в команде инфраструктуры.

Но были и проблемы, которые хотелось решить в первую очередь:

Команда инфраструктуры перегружена. На глобальные улучшения не хватало времени и сил из-за текущей операционки. Например, мы очень долго хотели, но не могли избавиться от Elasticsearch в своём стеке, или продублировать инфраструктуру у другого облачного провайдера, чтобы избежать рисков (тут могут посмеяться те, кто уже пробовал в мультиклауд).

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

Есть программисты, а есть инженеры инфраструктуры. Несмотря на то, что у нас достаточно хорошо была развита культура DevOps, всё ещё было это разделение. Два класса людей с абсолютно разным опытом, которые говорят на разных языках и пользуются разными инструментами. Они, конечно, дружат и общаются, но часто не понимают друг друга из-за совершенно разного опыта.

Онбординг SRE-команды

Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов первый шаг к полноценной структуре SRE.

На проект мы выделили 4 месяца и поставили три цели:

1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
2. Написать IaC описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Состав участников: 9 человек, 6 из них из команды разработки, 3 из инфраструктуры. На 4 месяца они должны были уйти из обычной работы и погрузиться в обозначенные задачи. Чтобы поддерживать жизнь в бизнесе, ещё 3 человека из инфраструктуры остались дежурить, заниматься операционкой и прикрывать тылы. В итоге проект заметно растянулся и занял больше пяти месяцев (с мая по октябрь 2019-го года).

Две составляющие онбординга: обучение и практика

Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

Обучение. На обучение выделялось минимум 3 часа в день:

• на чтение статей и книг из списка литературы: Linux, сети, SRE;
• на лекции по конкретным инструментам и технологиям;
• на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Ещё один инструмент обучения внутреннее демо. Это еженедельная встреча, на которой каждый (кому есть, что сказать) за 10 минут рассказывал о технологии или концепции, которую он внедрил в нашем коде за неделю. Например, Вася поменял пайплайн работы с Terraform-модулями, а Петя переписал сборку образов на Packer.

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



Практика. Вторая часть онбординга создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.



Реверсинжиниринг инфраструктуры. Это первый этап, на котором разобрали, что где задеплоено, как что работает, где какие сервисы работают, где какие машины и их размеры. Всё полностью задокументировали.

Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.

Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

Пересоздание стендов для нагрузочного тестирования и продакшена. Это четвёртый этап, который должен был идти после онбординга, но его пока отложили, так как профита от него, как ни странно, гораздо меньше, чем от дев-окружений, которые создаются/пересоздаются очень часто.

Вместо этого мы переключились на проектную деятельность: разбились на небольшие подкоманды и занялись теми глобальными инфраструктурными проектами, до которых раньше не доходили руки. Ну и конечно включились в дежурства.

Практики Extreme Programming в инфраструктуре

Главное, что мы, как программисты, принесли с собой это практики Extreme Programming, которые используем в работе. XP гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.

Нет ни одного программиста, который бы не использовал хотя бы несколько из практик Extreme Programming, даже если он об этом не знает. При этом в мире инфраструктуры данные практики обходят стороной, несмотря на то, что они в очень большой степени пересекаются с практиками из Google SRE.

О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.

Всё могло бы сложиться хорошо, но так не бывает.

Технические и антропогенные проблемы на пути

В рамках проекта было два вида проблем:

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

Мы начали развивать команду онбординга так, как стали бы делать это с любой другой командой программистов. Мы ожидали, что будут обычные стадии формирования команды по Такману: шторминг, норминг, а в конце мы выйдем на производительность и продуктивную работу. Поэтому не переживали, что вначале возникали какие-то сложности в общении, принятии решений, сложности с тем, чтобы договориться.

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

• Опытные программисты с годами опыта, за которые они выработали свои подходы, привычки и ценности в работе.
• Другая группа из мира инфраструктуры со своим опытом. У них другие шишки, другие привычки, и они тоже считают, что знают как правильно жить.

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

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

Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта что больше нравится. Возможно, они помогут.

Итоги онбординга

По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

• Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
• Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
• Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
• Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли

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

Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

Примерно так же я ощущаю себя сейчас, когда работаю с инфраструктурой. Текущие инструменты только формируются, многие из них ещё не вышли в релиз и имеют версию 0.12 (привет, Terraform), а у многих регулярно ломается обратная совместимость с предыдущими версиями.

Для меня, как энтерпрайз-разработчика, использовать на проде такие вещи абсурд. Но других просто нет.

Читайте документацию. Как программист, я относительно редко обращался к докам. Я достаточно глубоко знал свои инструменты: любимый язык программирования, любимый фреймворк и БД. Все дополнительные инструменты, например, библиотеки, обычно написаны на том же языке, а значит всегда можно посмотреть в исходники. IDE всегда подскажет, какие и где нужны параметры. Даже если я ошибусь, то быстро это пойму, запустив быстрые тесты.

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

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

Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

PS: Я специально не стал затрагивать в этой статье темы микросервисов, Кубернетеса и прочие хайповые вещи, с которыми приходится учиться жить, так как это большая тема для отдельной статьи.

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится два блока по два дня и домашние задания между ними.

Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.

Это расшифровка выступления на TechLeadConf 2020-06-09. Прежде чем начнем, попробуйте ответить для себя на вопрос какие у вас ожидания от взаимодействия с инфраструктурой? Например сколько времени займет:

• Развернуть новое окружение для тестов.
• Обновить версию java и/или ОС внутри контейнера.
• Выдать права доступа на сервер.

А теперь умножьте свои ожидания на двое, и вы получите суровую реальность. Не приятненько как-то, да?

Особенно когда ты тот самый человек со стороны инфраструктуры, который говорит, что всё будет долго. Но так долго не потому, что я такой-сякой чопорный. Для этого, как правило, есть объективные причины. Давайте разбираться почему так происходит и что с этим делать.

Инфраструктура как она есть

Cлучайности + Договоренности + Процессы = Инфраструктура

Прежде чем ответить на вопрос почему так долго? Предлагаю разобраться с тем что такое инфраструктура и как она появляется. Зачастую, процессы появления инфраструктуры изоморфны и похожи между собой. Рассмотрим собирательный образ некого сферического коня, не проводящего в вакуме: появления инфраструктуры для разработки коробочного приложения.

1. Случайность. Есть приложение. Но оно не появляется просто так, его разрабатывают вполне конкретные люди. Со временем или сразу появляется потребность развернуть/запустить приложение где-то(Спасибо Кэп!). В нашем случае лет 10-15 назад было отправлено письмо с просьбой смонтировать сервер в стойку. У кого-то это просьба в телеграмм чате настроить сервер. Суть в том, что инфраструктура это про то, что вас кто-то что-то попросил сделать, развернуть сервис. Изменения не происходят потому что вам так захотелось, за изменениями стоят люди.
2. Договоренности. Со временем, случайные запросы на изменения через jira, email, slack могут перерасти в хаотичный поток запросов. В нашем случае необходимо было разворачивать множество окружений похожих на клиентские. Но бывает можно услышать "если хотите ускорить развёртывание, то не пишите нам в четверг, потому что мы ходим в серверную по средам". Появляются договоренности.
3. Процессы. Апогеем становится преобразование договоренности в процесс. Появляется формальный процесс: заведите таску в jira, заполните необходимые поля и в течение 7 дней первый освободившийся инженер создаст вам новое окружение.

Инфраструктура стремится к хаосу

Как вы понимаете, монтаж серверов в стойку, процесс не быстрый, а разработка должна лететь. Но всё меняется, и приложение было контейнеризировано. Появилась возможность создавать динамически виртуалки на CoreOS и запустив compose файл получить окружение похожее боевое. Этакий k8s на минималках. И тут появился первый звоночек: а кто отвечает за YML файлике в git? Кто описывает инфру? Закономерно, код без присмотра начинает дурно пахнуть и привет групповая безответственность. Растет технический долг за счет быстрых и незаменимых подпорок из велосипедов. Меняется команда с одной стороны, потом с другой. И всё. Приплыли. Наступает ОПА момент когда инфраструктура работает, но никто не видит картинку целиком и не понимает почему она работает именно так. Это ни хорошо и ни плохо. Это данность: Инфраструктура стремится к хаосу, как и наша вселенная стремится к тепловой смерти.

Как бороться с Хаосом?

Бумажки и инструкции на защите от хаоса

Написать инструкции может прийти первым на ум, когда вы захотите бороться с хаосом. У меня тут есть, забавная история, как в одной ооооочень большой организации любили писать бумажки почти на каждый чих. Однажды, там для переезда сервиса согласовали временную схему сети на пару недель и выставили сервис в интернет. Соль в, том что я нашел это спустя пять лет. А на минутку это: нефтебаза в аэропорту с доступом в сеть ЦОД. Не хорошо как-то. Бумажка есть, а реальность показывает другое.

Agreements as Code

Аналогичная ситуация будет с задачами в Jira. Вас попросили, подготовить новое окружение. Вы что-то сделали и забыли как-оно там было настроено. Но если те же договорённости формализовать в виде кода. Пусть даже на своем DSL, или просто кодом на Ansible написали. Итогом у вас есть воспроизводимое решение и единая точка правды. Кто-то то поправил код в репозитории и вот обновленная версия приложения уже в проде. Но стоит ли это все эти договоренности автоматизировать? Стоит ли овчинка выделки?

Agreements as Code внедрять нельзя забить

Для ответа на вопрос автоматизировать или нет процесс/договоренности я выработал матрицу для принятия решений. Она концептуально похожа на матрицу Эйзенхауэра.

• *ОПА степень "проблемности" проблемы. Насколько вы/ваши коллеги/заказчики страдаете.
• Стоимость решения сколько времени/денег стоит решить проблему.

Рассмотрим краевые случаи:

• Проблема огромная, решается дешево надо делать. Инструкция по заведению пользователей из confluence который пользоваться каждый день, замечательно заменяется скриптом, который формализует договоренности.
• Проблема маленькая, решается дешево спорно, делать по остаточному принципу. Разбираться с REST api редкого сервиса, чтобы раз в год обновить DNS может быть не лучшим выбором для инвестиции времени. Но на долгой дистанции может пригодиться.
• Проблема маленькая, решается дорого игнорировать. Как часто вам приходится обновлять подпись к email? раз в год? в три?
• Проблема огромная, решается дорого спорно, необходимо десять раз подумать, т.к. без опыта можно сделать только хуже. Например, скриптики которые автоматизировали процессы и договорённости вдруг стали стандартом, все пользуют и не знают как оно работает. Собственно, та самая *ОПА когда вам надо рефакторить IaC.

Ручной труд -> Механизация -> Автоматизация

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

• Ручной труд нет автоматизации, вы руками проделываете всё, собираете шишки и понимаете, как выглядит процесс и какие в нем бутылочные горлышки.
• Механизация первые попытки упростить себе жизнь. Статья в confluence с собранными шишками превращается в скрипт автоматизирующий отдельные проявления рутины. Но требующий человека для принятия решений.
• Автоматизация "Слава роботам"(с) Бендер. Человек задействован минимально, появляются различные * as Service и позволяют другим людям автоматизировать их работу.

Когда эволюционировать и переходить на следующий уровень автоматизации, а когда нет?

• Проблема огромная, автоматизируется легко надо делать. Заведение пользователей замечательно заменяется интеграцией, например, с LDAP и решает проблемы на корню. Инструкция -> скрипт -> LDAP.
• Проблема маленькая, автоматизируется легко имеет смыл, т.к. на дальней дистанции можно переиспользовать наработки и не изобретать велосипед по новой, ваше знание сохранено и со временем может перерасти в сервис. Если посмотреть на AWS, то предоставляется множество * as Service на любой вкус, а ведь когда-то оно тоже могло начинаться с простого скрипта. Например, я завел приватный репозиторий, где хранятся такого рода скрипты.
• Проблема маленькая, автоматизируется сложно скорее нет. Но для кого-то даже такое редкое действие как обновление подписи к email может быть актуально, у нас на дружественном проекте такое разрабатывают; говорят, что у одного крупного аутсорсера есть специальный web портал на котором можно получить свою подпись.
• Проблема огромная, автоматизируется сложно скорее да, если ваши договоренности представлены в виде кода, то когда настанет *ОПА(а это неизбежно, т.к. всё стремится к хаосу!), у вас будет возможность отрефакторить код.

По мере развития инфраструктуры, договоренности формализуются в виде кода и стремятся стать * as Service.

Инфраструктуру можно и нужно рефакторить. Но не всегда

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

• Разобраться как оно работает и удовлетворить собственное эго.
• Ускорить внесение изменений.
• Уменьшить количество падений сервисов
• ...

Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев

В моем случае, досталось в наследство самописное configuration management решение. Оно представляло инфраструктуру в виде кода, оно работало, но его поддержка было сложной, т.к. оно было хрупкой, никто не хотел его поддерживать. Планомерным итогом стала замена его на Ansible, подробности можно глянуть тут Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев. Почему 1,5 года заняла миграция? Ответ прост 80% был reverse engineering как оно работает и только 20% непосредственно написание плэйбуков, ролей и миграция. Сам же процесс был прост:

1. Сформировать список серверов.
2. Выбрать сервер из списка не перенесенных.
3. Зафиксировать текущие договоренности.
4. Разобраться как работает.
5. Описать в виде кода.
6. Вернуться на пункт 2.

Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек

На дружественном проекте занялись автоматизацией развертывания окружений у заказчиков и делали это через Ansible. Но спустя какое-то врем пришло понимание, что получившиеся плэйбуки страшно запускать на боевых серверах, т.к. нет уверенности что они не свалятся с ошибкой. Ситуацию еще усугубляло то, что до клиентов был air gap(инженеру могло потребоваться прийти на площадку к заказчику где нет интернета). Задача была стабилизировать плэйбуки и наладить процесс выпуска. Как решали можно почитать в Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек, но если кратко:

1. Составить список существующих ролей.
2. Выбрать одну роль.
3. Покрыть тестами и зафиксировать текущие договоренности.
4. Внести правки в плэйбуки/роли, исправив причины падения.

Как реализовано тестирование Ansible ролей?

Так исторически сложилось, что использовался репозиторий в котором лежали все роли. Был создан Jenkins Pipeline, который:

1. Вычитвает конфиг из репозитория что тестировать.
2. Генерирует динамически стадии для Jenkins.
3. Запускает lint для всех ролей и плэйбуков.
4. Запускает molecule для всех ролей

Реафаторинг IaC

Мы то с вами помним, что инфраструктура эволюционирует и формализуется в скрипты и/или множество * as Service. А с этим можно работать как с кодом и переиспользовать практики по рефакторингу кода. Из предыдущих сценариев выбивается нечто общее:

1. Определяем измеримую цель.
2. Проверяем наличие нужных знаний и времени на изменения.
3. Выбираем маленький кусочек инфраструктуры.
4. Разбираем что он делает.
5. Формализуем договоренности и покрываем их тестами.
6. Отдыхаем(это важно! иначе сгоришь оставив недоделанным работу).
7. Повторяем.

И это по сути своей то же самое что и рефакторинг кода. Только со своей спецификой: несовершенный тулинг, нет синтаксического сахара, выглядит странно. Здесь так же необходимо что бы у вас было:

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

Ускоряем ускорение

Со временем, внесение изменений в договоренности, в IaC может замедлиться и это нормально. Долго думал, как формализовать договоренности, и пришла идея изобразить историю развития проекта в цифрах и поискать закономерности. На график изображено:

• Синяя линия Количество строк в YML файлах. Сложно померить договоренности, но можно допустить, что кол-во виртуальных машин коррелирует с ними.
• Красная заливка Количество тестируемых Ansible ролей и плэйбоуков.
• Маджентовая линия Количество инженеров поддерживающих и улучшающих инфраструктуру.

По графику можно увидеть, что:

• Количество кода растет линейно и прогнозируемо.
• Количество тестов отложенное коррелирует с количеством кода и растет по экспоненте.
• Количество инженеров константно.

Напрашивается вывод, что если бы не тесты инфраструктуры, то не получилось бы поддерживать рост инфраструктуры тем же количествов людей. Тесты на инфраструктуру удешевляют/ускоряют ее изменения.

Используй IaC testing pyramid. Не откладывай не потом!

Годом ранее на DevopConf рассказывал Что я узнал, протестировав 200 000 строк инфраструктурного кода и подробно рассмотрел пирамиду тестирования инфраструктуры. Ровно таже идея, что в разработке, но для инфраструктуры: идем от дешевых быстрых тестов, которые проверяют простые вещи, например отступы, к дорогим полноценным тестами разворачивающих цельную инфраструктуру.

• Static Analysis Статистический анализ кода, без запуска. Линтеры, например.
• Unit IaC должна состоять из простых кирпичиков и вот их тестируем. В случае Ansible это роли тестируемые при помощи Molecule.
• Integration Очень похожи на unit, но представляют комбинацию ролей описывающих целевую конфигурацию сервера.
• E2E Цельная инфраструктура, состоящая из множества серверов.

Когда начинать писать тесты?

Ок, договоренности в инфраструктуре можно представить как код. А потом можно рефакторить. А если есть тесты то еще и не закопаться в рефакторинге. Но вот вопрос, когда начинать писать тесты? Рассмотрю пару проектов.

Проект 1

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

Проект 2

На другом проекте рефакторинг начался с линтинга и весьма бодро пошёл. Но и кодовая база была скромная.

Вынесенный урок, что перевернутая пирамида тестирования не работает и с тестами не надо затягивать. Можно ориентироваться на такие цифры SLOC:

• 2000 линтинг должен быть.
• 4000 пора делать юнит тесты
• 6000 время интеграционных тестов.
• 8000 E2E тесты мерещат на горизонте.

Lessons learned

1. Инфраструктура стремится с хаосу.
2. Agreements as Сode внедрять нельзя забить.
3. Ручной труд -> Механизация -> Автоматизация.
4. Инфраструктуру можно и нужно рефакторить. Но не всегда.
5. Тесты на инфраструктуру удешевляют/ускоряют ее изменения.
6. Используй IaC testing pyramid. Не откладывай не потом!

Links

• Slides
• Video
• English Version
• A list of awesome IaC testing articles, speeches & links
• Что я узнал, протестировав 200 000 строк инфраструктурного кода
• Как начать тестировать Ansible, отрефакторить проект за год и не слететь с катушек
• Ansible: Миграция конфигурации 120 VM c Coreos на Centos за 18 месяцев
• Podcast nsfw.co.in/04 Agreements as Code
• Cross post from personal blog

Terraform это опенсорс-инструмент IaC (инфраструктура как код), который предоставляет согласованный рабочий процесс в CLI для управления сотнями облачных сервисов. Terraform преобразует облачные API в декларативные файлы конфигурации.

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

В статье рассмотрим несколько способов подготовки инфраструктуры в разных окружениях. У каждого из них есть свои преимущества и недостатки.

Введение

Каждое приложение проходит через несколько окружений до деплоймента в продакшен. Эти окружения должны быть максимально похожи друг на друга. Воспроизводить баги и быстро исправлять их будет несложно чего не скажешь о воспроизведении аналогичной инфраструктуры в каждом окружении вручную. Terraform упрощает создание инфраструктуры в мультиоблачном окружении.

Раз Terraform это инструмент IaC, мы прописываем инфраструктуру в коде, поэтому ее можно приспособить для разных окружений с помощью модульного подхода.
Рассмотрим способы создания инфраструктуры в нескольких окружениях.

Предварительные требования

Если у вас еще нет опыта работы с Terraform, сначала лучше почитать эту статью.

Используем папки метод 1

Здесь мы дублируем одну и ту же инфраструктуру в каждой папке с разными значениями в файле terraform.tfvars. Это не идеальный вариант, если у вас одинаковая инфраструктура во всех окружениях.

Папка представляет отдельное окружение. У вас может быть бэкэнд в каждой папке, а может не быть ничего общего между папками. В каждой папке могут находиться файлы outputs.tf, providers.tf, variables.tf и т. д. При выполнении команд terraform приходится переходить в соответствующую папку и выполнять три команды: init, plan, apply.

Использование папок (метод 1)

Преимущества:

• для каждого окружения можно легко добавлять или удалять ресурсы,
• изменения в одном окружении не влияют на другие окружения.

Недостатки:

• дублирование кода;
• если нужно изменить ресурс, приходится делать это во всех окружениях.

Используем папки метод 2

Здесь у нас одна и та же инфраструктура в общих файлах, но для каждого окружения есть отдельный файл terraform.tfvars. Это не идеальный вариант, если у вас разные инфраструктуры во всех окружениях.

Раз файлы main.tf и variables.tf у нас одинаковые, при выполнении команд terraform мы передаем разные переменные в зависимости от окружения. Например, если у нас три окружения, для создания инфраструктуры мы должны выполнить следующие три команды:

// Dev Environmentterraform plan --var-file="tfvars/environment/dev.tfvars"// QA Environmentterraform plan --var-file="tfvars/environment/qa.tfvars"// Prod Environmentterraform plan --var-file="tfvars/environment/prod.tfvars"

Использование папок (метод 2)

Преимущества:

• код не дублируется;
• если нужно изменить ресурс, не приходится делать это во всех окружениях.

Недостатки:

• для каждого окружения нельзя легко добавлять или удалять ресурсы;
• изменения в одном окружении влияют на другие окружения, ведь мы используем одни и те же файлы с разными файлами переменных.

Воркспейсы

Terraform начинается с одного воркспейса с именем default. Это дефолтный воркспейс, который, в отличие от остальных, невозможно удалить. Если вы никогда явно не использовали воркспейсы, значит, вы работали только в воркспейсе default.
Воркспейсы управляются командами terraform workspace. Существует целый набор таких команд. Например, terraform workspace new создает воркспейс.

Модули

Модуль это контейнер для нескольких ресурсов, которые используются вместе. В каждой конфигурации Terraform есть хотя бы один модуль root-модуль. Root-модуль обычно состоит из ресурсов, определенных в файлах с расширением .tf в главном рабочем каталоге.

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

Ниже описываем использование комбинации папок и модулей. Мы импортируем модуль в главный файл и можем передавать соответствующие входные переменные в зависимости от окружения, как показано на схеме.

Несколько окружений

Terragrunt

Terragrunt это тонкая обертка, которая предоставляет дополнительные инструменты для соблюдения принципа DRY в конфигурациях, работы с несколькими модулями Terraform и управления удаленным стейтом.

Подробнее об этом на их официальном сайте.

Итоги

• Terraform это опенсорс-инструмент IaC, который предоставляет согласованный рабочий процесс в CLI для управления сотнями облачных сервисов.
• Обычно мы деплоим инфраструктуру в нескольких окружениях, которые мы используем для разработки, стейджинга, тестирования и продакшена.
• Есть пять способов написать многоразовый код для разных окружений в Terraform.
• Самый популярный из них папки. Работать с папками можно двумя методами.
• Terraform начинается с одного воркспейса с именем default. Это дефолтный воркспейс, который, в отличие от остальных, невозможно удалить.
• Модуль это контейнер для нескольких ресурсов, которые используются вместе. Использование модулей можно настроить таким образом, чтобы один и тот же модуль подходил для разных окружений без изменения кода.
• Terragrunt это тонкая обертка, которая предоставляет дополнительные инструменты для соблюдения принципа DRY в конфигурациях, работы с несколькими модулями Terraform и управления удаленным стейтом.

Итак, мы рассмотрели несколько способов создать инфраструктуру для разных окружений с помощью Terraform. У каждого из них свои преимущества и недостатки. Эти способы можно сочетать друг с другом.

Вспомним классику.

Разработчики с трудом выкатывают фичи раз в год. Зато админы довольны и радостны им больше не нужно уходить с работы, они теперь работают круглосуточно, и руководство их ласково называет нянечки для разрабов. Технологии начинают откатываться. Отладка требует сотни передач из отдела в отдел все с огромным энтузиазмом перекидывают друг другу дохлую свинью через забор. Даже свинья улыбается. Долгое ожидание сервера под проект запросил сервер, получил посмертно, за заслуги перед компанией. Баги в продакшене с полной уверенностью рассчитывают увидеть XXII век. SLA 50% и седые до прозрачной белизны владельцы бизнеса. Упал сервис не проблема, подождём часок или два, пока поднимется. Универсальные инженеры на грани психоза на столе у каждого по две полупустых баночки бензодиазепиновых транквилизаторов и пачка SSRI-антидепрессантов.

Вздрогнули? И с лёгким сердцем обратно в нормальный мир, где есть DevOps-философия и DevOps-инструменты, как часть неё.

19-21 августа пройдёт онлайн-интенсив Слёрм DevOps: Tools&Cheats. Мы покажем IDDQD из мира DevOps.

Да есть книги и мануалы одни дают теорию, другие информацию. Но только на конференциях и интенсивах можно получить практику из первых рук. Именно практику, а не пересказ тех самых мануалов.

Слёрм DevOps: Tools&Cheats:

• за 3 дня получить представление об основных инструментах;
• после прохождения курса можно сразу внедрять практики у себя на работе;
• много, даже очень много практических заданий;
• спикеры практикующие DevOps-инженеры и разработчики с многолетним опытом;
• никто не будет отнимать время объемными лекциями по философии DevOps, у нас упор на инструменты и практику.

С программой курса и спикерами вы можете ознакомиться и познакомиться на странице интенсива.

Поговорим откровенно? Почему мы создали этот курс? Потому что нас тоже бесит:

• что курсы для практиков ведут теоретики;
• что решением проблем считают не подход, а должность;
• что 80% курсов по девопсу рассказывают о концепции и философии. А инструменты где? Чем гвозди забивать, микроскопом или лучше Macbook Pro?
• бесит, когда к концу обучения забыл, что было в начале, а результатов надо ждать от 6 до 8 месяцев.

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

За эти три дня вы научитесь основным DevOps-практикам, которые позволят:

• организовать командную работу с Git;
• автоматизировать рутинные операции;
• настроить мониторинг и интегрировать его с мессенджерами;
• развернуть серверы, используя подход Infrastructure as Code;
• обеспечить процесс CI;
• И ещё немного практических читов из реальной работы.

Слёрм DevOps пройдет с 19 по 21 августа 2020. Каждый день начинаем в 10:00 и заканчиваем в 19:00, с перерывами на чай и обед.

Инструменты DevOps + IDDQD + IDKFA и за работу. И пусть кто-то только попробует помешать.

Всем привет!

Автотесты под Android это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.

Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

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

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У Авито есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.

Процесс написания тестов

На первом шаге давайте попробуем написать тесты у себя на машине и запустить их локально.

Выбор инструментов для написания автотестов

Стоит сразу определиться со стеком технологий, который мы будем использовать для написания тестов.

Первая развилка это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер мы за нативные решения. По нашему опыту, они:

• стабильнее;
• быстрее;
• лучше интегрированы в IDE;
• не содержат слоев, которые вносят нестабильность и заставляют иметь суперширокие экспертные знания.

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

• Appium vs Espresso: Key Differences.
• Appium vs. Espresso: Which Framework to Use for Automated Android Testing.
• Appium vs Espresso: The Most Popular Automation Testing Framework in 2019.

На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.

Kaspresso

Kaspresso это фреймворк, который:

• предоставляет DSL, значительно облегчающий написание автотестов;
• дает встроенную многоуровневую защиту от флекающих тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запуска любых ADB-команд внутри тестов;
• предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
• описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим Orchestrator. AndroidJUnitRunner делает то, что от него и требуется просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных девайсах;
• перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
• подготавливать отчеты о прогоне в разных форматах;
• отображать результаты прогона (желательно Allure based);
• поддержать истории прогонов для дальнейшего анализа;
• просто интегрироваться с вашей инфраструктурой.

На рынке есть несколько сторонних раннеров. Среди всех них, самым перспективным мы считаем Marathon, который довольно быстро настраивается и удовлетворяет части обозначенных выше требований. Например, он поддерживает распараллеливание тестов и подготовку результатов прогона в формате, пригодном для отображения в Allure.

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

• Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
• Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

Кроме того, мы считаем, что раннер должен быть проприетарным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

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

1. Настоящий девайс.
   Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
   Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под чистым мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
   Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
   Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.
   Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
   Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

• Docker image от Avito;
• Docker image от Google;
• Docker image от Agoda.

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

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

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

Итак, что вам примерно предстоит:

• Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
• Самое трудоемкое это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
  Дальнейшая накатка необходимого ПО, встраивание в сети и прочее это все за DevOps-инженерами.
• На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
  В его настройке опять-таки помогают DevOps-инженеры.
• Связка полученного сервиса с Test Runner.
  Одна из задач AvitoRunner сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить AvitoRunner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

• вывод отчета по прогону тестов (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

Мы постарались описать основные части становления автотестирования под Android. Надеемся, что теперь у вас в головах сложится тот самый пазл, который позволит видеть картину целиком.

Следите за анонсами на нашем сайте и в телеграм-канале.