Инструменты devops что это

☸️ Полный список инструментов DevOps

«Разрабатывайте системы, а не программного обеспечения»

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

Что такое DevOps?

Нет единого определения или правильного ответа на вопрос «Что такое DevOps»?

DevOps не является инструментом, технологией или какой-либо структурой; это больше философия и концепция.

Это набор практик, сочетающий разработку программного обеспечения (Dev) и ИТ-операции (Ops), который помогает сократить жизненный цикл разработки системы и обеспечить непрерывную интеграцию и поставку с высоким качеством программного обеспечения.

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

Инструменты DevOps

Планирование и сотрудничество

JIRA – это один из популярных инструментов управления проектами, разработанный Atlassian, который используется для отслеживания проблем, ошибок и проектов.

Это позволяет пользователю отслеживать проект и выпускать статус.

Его можно легко интегрировать с другими продуктами Atlassian, такими как Bitbucket, в дополнение к другим инструментам DevOps, таким как Jenkins.

Slack

Slack – это бесплатный инструмент для совместной работы на основе облака, который позволяет групповую коммуникацию и совместную работу в одном месте.

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

Он также может быть легко интегрирован с другими инструментами, такими как GIT, Jenkins, JIRA и т. д.

Zoom – это платформа для веб-конференций и мгновенного обмена экранами.

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

Неважно, насколько велика ваша команда, Zoom способен принять до 1000 участников на онлайн-встречу.

Источник

Что такое методология DevOps и кому она нужна

Разбираемся, в чём суть методологии и кому она может принести пользу.

Также поговорим о DevOps-специалистах: их задачах, зарплатах и навыках.

Фото Matt Moor / Flickr / CC BY-SA

Что такое DevOps

DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании. Если ИТ-специалисты из разных отделов недопонимают суть задач друг друга, выпуск новых приложений и обновлений для них затягивается.

DevOps формирует «бесшовный» цикл разработки, тем самым помогая ускорить выпуск программного продукта. Ускорение достигается за счет внедрения систем автоматизации. Плюс программисты начинают участвовать в настройке серверов и поиске багов, например, они могут писать автоматизированные тесты.

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

Когда разработчик понимает, с чем сталкивается администратор при настройке сервера, он постарается сгладить возможные «острые углы» в коде. Это сокращает количество багов при развертке приложения — по статистике оно уменьшается примерно в пять раз.

Кому нужна и не нужна методология

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

Исключение составляют стартапы, но и здесь все зависит от масштабов проекта. Если ваша цель — запустить минимально жизнеспособный продукт (minimum viable product, MVP), чтобы протестировать новую идею, то можно обойтись и без DevOps. Например, основатель Groupon в начале работы над сервисом сам вручную размещал все предложения на сайте и собирал заказы. Никаких инструментов автоматизации он не использовал.

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

Как внедрить DevOps

Далее — несколько рекомендаций для перехода на новую методологию.

Выявите проблемы в бизнес-процессах. Перед внедрением методологии выделите цели и проблемы организации. От них будет зависеть стратегия перехода на DevOps. Для этого составьте список вопросов, например:

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

Начните с малого. Выберите процесс, который отнимает больше всего времени и сил при выпуске обновлений, и автоматизируйте его. Это может быть тестирование или процесс развертывания приложений. Эксперты советуют первым делом внедрить инструменты распределенного контроля версий. С ними проще управлять исходниками. Среди таких решений наиболее известны Git, Mercurial, Subversion (SVN) и CVS.

Также стоит обратить внимание на системы непрерывной интеграции, ответственные за сборку и тестирование конечного продукта. Примеры таких инструментов: Jenkins, TeamCity и Bamboo.

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

Критика DevOps

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

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

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

Фото Ed Ivanushkin / Flickr / CC BY-SA

Кто такой DevOps-инженер

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

Фишка DevOps-инженера в том, что он совмещает множество профессий: админа, разработчика, тестировщика и менеджера.

Джо Санчес, DevOps-евангелист из VMware, компании-разработчика программного обеспечения для виртуализации, выделил ряд навыков, которыми обязан обладать DevOps-инженер. Помимо очевидного знания методологии DevOps, этот человек должен иметь опыт администрирования ОС Windows и Linux и опыт работы с инструментами автоматизации вроде Chef, Puppet, Ansible. Еще он должен уметь писать скрипты и код на паре-тройке языков и разбираться в сетевых технологиях.

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

Кто нанимает

DevOps-инженеры могут принести пользу любой организации, чья деятельность связана с разработкой приложений или управлением большим количеством серверов. DevOps-инженеров нанимают ИТ-гиганты вроде Amazon, Adobe и Facebook. Еще они работают на Netflix, Walmart и Etsy.

Не нанимают DevOps-инженеров только стартапы. Их задача — выпустить минимально жизнеспособный продукт, чтобы проверить новую идею. В большинстве случаев стартапы могут обойтись без DevOps.

Сколько платят

DevOps-инженеры зарабатывают больше всех в отрасли. Средний заработок таких специалистов по миру составляет от 100 до 125 тыс. долларов в год.

В США они получают 90 тыс. долларов в год (500 тыс. рублей в месяц). В Канаде им платят 122 тыс. долларов в год (670 тыс. рублей в месяц), а в UK — 67,5 тыс. фунтов стерлингов в год (490 тыс. рублей в месяц).

Что касается России, то московские компании готовы платить DevOps-специалистам от 100 до 200 тыс. рублей в месяц. В Санкт-Петербурге работодатели чуть щедрее — предлагают 160–360 тыс. рублей в месяц. В регионах указывают зарплату 100–120 тыс. рублей в месяц.

Как стать специалистом по DevOps

DevOps — это относительно новое направление в IT, поэтому устоявшегося перечня требований к DevOps-инженерам нет. В вакансиях среди требований на эту должность можно встретить как навыки администрирования Debian и CentOS, так и умение работать с дисковыми RAID-массивами.

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

Проще всего стать DevOps-инженером будет сисадмину или разработчику. У них уже есть ряд навыков, которые нужно просто развить. Главная задача — подтянуть минимальный набор знаний по DevOps, понять, как работать с инструментами автоматизации и заполнить пробелы в навыках администрирования, программирования и виртуализации.

Чтобы понять, где знаний пока не хватает, можно воспользоваться мини-википедией на GitHub или ментальной картой. Резиденты Hacker News также рекомендуют почитать книги «Проект „Феникс“» и «Руководство по DevOps» (которые мы упоминали выше) и «Философия DevOps. Искусство управления IT» под грифом O’Reilly Media.

Еще можно подписаться на рассылку Devops Weekly, почитать статьи тематического портала DZone и начать общаться с DevOps-инженерами в Slack-чате. Еще стоит изучить бесплатные курсы на Udacity или edX.

Источник

Что такое DevOps и зачем он нужен?

Почему полезно работать с DevOps, где применять эту технологию и какие существуют инструменты. Объясняет Алексей Климин из компании «Атвинта».

Фронтенд, Бэкэнд, Админ, DevOps. Обожаю все оптимизировать и автоматизировать. Постоянно ищу новые технологии и способы их внедрения.

Что это за технология

Термин DevOps образован от английских слов development и operations. Это подход, методология и даже культура и философия процесса разработки, при котором программисты, тестировщики и системные администраторы могут работать над продуктом быстрее и эффективнее. Подход помогает снизить ошибки при передаче проекта от разработчиков к тестировщикам и сисадминам и наладить между ними взаимодействие. В основе лежит идея, что разработка, тестирование и эксплуатация цифровых продуктов — это единый, бесшовный и циклический процесс.

Сама по себе тема DevOps довольно объемная. Это автоматизация процессов подготовки инфраструктуры как для разработки, так и для тестирования приложения, а также для его эксплуатации. Сюда же входят автоматизация деплоя и мониторинг.

Рассмотрим на примере заказной разработки веб-приложений, с какими проблемами сталкиваются разработчики и как их устранить с DevOps-подходом.

Вариант сервис-ориентированной архитектуры ПО, ориентированный на взаимодействие небольших, слабо связанных и легко изменяемых модулей — микросервисов.

Проблемы при работе без DevOps

Много действий при передаче на тестирование

Разработчик устанавливает у себя на машине все необходимое: язык программирования, на котором будет вестись разработка, например PHP 7.0, базу данных, MySQL 5.7 и веб-сервер, Apache. Какая операционная система и какие версии библиотек и зависимостей будут установлены на сервере, неизвестно.

После того как нужная функциональность приложения реализована, требуется ее протестировать.

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

QA-специалист устанавливает все необходимое на тестовый стенд, разворачивает приложение и принимается тестировать.

Если в процессе тестирования появляется новая версия разработки, то приходится повторять процедуру. Разработчику нужно снова создать архив, передать тестировщику; а тому, в свою очередь, снова развернуть приложение.

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

Несовместимость версий в тестовой среде и на сервере заказчика

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

В итоге при использовании на продакшне другого веб-сервера приходится настраивать приложение заново. А это дополнительное время.

Как DevOps улучшает процесс разработки

У нас в digital-агентстве «Атвинта» я настроил процессы таким образом, что сборка проекта, запуск автотестов и деплой на тестовый сервер происходят автоматически, а на продакшн — полуавтоматически. Если какой-либо из этапов завершился неудачно, разработчик получит оповещение.

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

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

Для единообразия окружения используем инструмент Docker.

После того как разработчик сделал определенный функционал, он отправляет код в репозиторий. Там вступает в работу процесс, называемый Continuous Integration/Continuous Delivery — непрерывная интеграция и непрерывная доставка (далее CI/CD).

Если процесс сборки и автоматического тестирования прошел успешно, приложение разворачивается на тестовом сервере (staging server), где специалист по QA проводит ручное тестирование либо тестирование с применением инструментов вроде Selenium — для автоматизации действий веб-браузера в случае веб-приложения.

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

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

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

Инструментарий для DevOps

Разнообразие инструментов DevOps невероятно велико, так что я перечислю лишь некоторые из них, которые применяю в своей работе.

Ansible — система управления конфигурациями, написанная на Python с использованием декларативного языка разметки (yaml) для описания конфигураций.

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

GitLab — система контроля версий со встроенной CI/CD.

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

Для мониторинга нагрузки серверов используется довольно популярный стек: Grafana + InfluxDB + Telegraf.

Grafana — это платформа с открытым исходным кодом для визуализации, мониторинга и анализа данных.

InfluxDB — база данных для хранения собранной статистики.

Telegraf — агент, который устанавливается на сервер и пересылает метрики, а также логи в базу InfluxDB.

Кому и для чего применять

Применение методологии DevOps поможет наладить бизнес-процессы и ускорить выход обновлений.

Источник

DevOps инструменты не только для DevOps. Процесс построения инфраструктуры автоматизации тестирования с нуля

Примечание: данная статья является переводом на русский язык оригинальной статьи «DevOps tools are not only for DevOps. Building test automation infrastructure from scratch». Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала, чтобы избежать искажения смысла при переводе на русский язык. Желаю вам приятного изучения!

В настоящее время специальность DevOps является одной из наиболее востребованных в IT-индустрии. Если вы откроете популярные сайты по поиску работы и зададите фильтр по зарплатам, то увидите, что вакансии, связанные с DevOps, находятся в начале списка. Однако важно понимать, что это в основном относится к позиции ‘Senior’, что подразумевает, что кандидат обладает высоким уровнем навыков, знанием технологий и инструментов. К этому также прилагается высокая степень ответственности, связанная с бесперебойной работой production. Однако мы стали забывать, что такое DevOps. Изначально это не был какой-то конкретный человек или департамент. Если поискать определения этого термина, то мы найдем много красивых и правильных существительных, таких как методология, практики, культурная философия, группа концептов и так далее.

Моя специализация – инженер по автоматизации тестирования (QA automation engineer), но я считаю, что она не должна быть связана только с написанием авто-тестов или разработкой архитектуры тестового framework. В 2020 году знания инфраструктуры автоматизации также необходимы. Это позволяет организовать процесс автоматизации самостоятельно, начиная от запуска тестов и заканчивая предоставлением результатов всем заинтересованным лицам в соответствии с поставленными целями. В результате чего, навыки DevOps являются обязательным фактором для выполнения данной работы. И все это хорошо, но, к сожалению, есть проблема (spoiler: данная статья делает попытки упростить это проблему). Она заключается в том, что DevOps – это сложно. И это очевидно, ведь компании не станут платить много за то, что легко сделать… В мире DevOps большое количество инструментов, терминов, практик, которыми нужно овладеть. Особенно это тяжело дается в начале карьеры и зависит от накопленного технического опыта.

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

О чем эта статья

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

Чего в этой статье нет

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

Это сделано по причине того, что:

Практика

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

Структура каждой секции

Для поддержания повествования в наглядном виде, каждая секция описана по следующему плану:

1. Локальный запуск тестов

Краткое описание технологии

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

Однако в качестве инструментов автоматизации я рекомендую использовать Selenium WebDriver для web-платформ и Appium для Android-платформы соответственно, так как на следующих шагах мы будем использовать Docker-образы, которые заточены на работу конкретно с этими инструментами. Более того, ссылаясь на требования в вакансиях, эти инструменты наиболее востребованы на рынке.

Как вы могли заметить, мы рассматриваем только web и Android-тесты. К сожалению, IOS – совершенно другая история (спасибо Apple). Я планирую продемонстрировать решения и практики, связанные с IOS, в следующих частях.

Ценность для инфраструктуры автоматизации

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

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения

Аналогичные инструменты

2. Системы контроля версий (Git)

Краткое описание технологии

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

Ценность для инфраструктуры автоматизации

И тут вы можете задать резонный вопрос: «Зачем он нам рассказывает о Git? Все это знают и используют как для кода разработки, так и для кода авто-тестов». Вы будете абсолютно правы, но в этой статье мы говорим об инфраструктуре и данная секция играет роль превью для секции 7: «Инфраструктура как код (IaC)». Для нас это означает, что вся инфраструктура, включая тестовую, описывается в виде кода, соответственно мы к ней тоже можем применить системы версионирования и получить аналогичные преимущества как для кода разработки и автоматизации.

Мы рассмотрим IaC более детально на шаге 7, но даже сейчас можно начать использовать Git локально, создав локальный репозиторий. Общая картина будет расширена, когда мы добавим к инфраструктуре удаленный репозиторий.

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения

Аналогичные инструменты

3. Контейнеризация (Docker)

Краткое описание технологии

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

Следующим этапом эволюции стали виртуальные машины (VM), которые решили проблему траты средств на неиспользуемые ресурсы. Эта технология позволила запускать приложения независимо друг от друга внутри одного сервера, выделяя полностью изолированное пространство. Но, к сожалению, любая технология имеет свои недостатки. Запуск VM требует полноценной операционной системы, которая потребляет CPU, RAM, хранилище и, в зависимости от OS, нужно учитывать расходы на лицензию. Эти факторы влияют на скорость загрузки и усложняют переносимость.

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

Конечно, технология контейнеризации не является чем-то новым и впервые была представлена в конце 70-х. В те времена проводилось много исследований, наработок, и попыток. Но именно Docker адаптировал эту технологию и сделал ее легкодоступной для масс. В наше время, когда мы говорим о контейнерах, в большинстве случаев мы имеем ввиду Docker. Когда мы говорим о Docker-контейнерах, мы подразумеваем Linux-контейнеры. Мы можем использовать Windows и macOS-системы для запуска контейнеров, но важно понимать, что в таком случае появляется дополнительная прослойка. Например, Docker на Mac незаметно запускает контейнеры внутри легковесной Linux VM. Мы еще вернемся к этой теме, когда будем обсуждать запуск Android-эмуляторов внутри контейнеров, так так здесь появляется очень важной нюанс, который необходимо разобрать более подробно.

Ценность для инфраструктуры автоматизации

Мы выяснили, что контейнеризация и Docker – это круто. Давайте посмотрим на это в контексте автоматизации, ведь каждый инструмент или технология должны решать какую-либо проблему. Обозначим очевидные проблемы автоматизации тестирования в контексте UI-тестов:

Selenium grid in docker

Этот инструмент является самым популярным в мире Selenium для запуска нескольких браузеров на нескольких машинах и управления ими из центрального узла. Для запуска необходимо зарегистрировать как минимум 2 части: Hub и Node(s). Hub – это центральный узел, который получает все запросы от тестов и распределяет их по соответствующим Nodes. Для каждого Node мы можем настроить конкретную конфигурацию, например, указав нужный браузер и его версию. Однако нам все еще необходимо самим позаботиться о совместимых драйверах для браузеров и установить их на нужные Nodes. По этой причине Selenium grid не используется в чистом виде, за исключением тех случаев, когда нам нужно работать с браузерами, которые нельзя установить на Linux OS. Для всех остальных случаев значительно гибким и правильным решением будет использование Docker-образов для запуска Selenium grid Hub и Nodes. Такой подход сильно упрощает управление узлами, так как мы можем выбрать нужный нам образ с уже установленными совместимыми версиями браузеров и драйверов.

Несмотря на негативные отзывы о стабильности работы, особенно при запуске большого числа Nodes параллельно, Selenium grid все еще остается самым популярным инструментом для параллельного запуска Selenium-тестов. Важно отметить, что в open-source постоянно появляются различные доработки и модификации данного инструмента, которые борются с различными узкими местами.

Этот инструмент является прорывом в мире Selenium, так как он работает сразу из коробки и сделал жизнь многих инженеров по автоматизации значительно проще. Прежде всего, это не очередная модификация Selenium grid. Вместо этого разработчики создали абсолютно новую версию Selenium Hub на языке Golang, что в связке с легковесными Docker-образами для различных браузеров дало толчок в развитии автоматизации тестирования. Более того, в случае Selenium Grid мы должны определить все требуемые браузеры и их версии заранее, что не является проблемой, когда работа идет только с каким-то одним браузером. Но когда речь идет о нескольких поддерживаемых браузерах, то Selenoid – это решение номер один, благодаря функции ‘браузер по требованию’. Все, что от нас требуется, это заранее выгрузить нужные образы с браузерами и обновить файл конфигурации, с которым взаимодействует Selenoid. После того как Selenoid получит запрос от тестов, он автоматически запустит нужный контейнер с нужным браузером. Когда тест завершится, Selenoid отставит контейнер, тем самым освободив ресурсы для следующих запросов. Такой подход полностью устраняет известную проблему ‘деградации узлов’, что мы часто встречаем в Selenium grid.

Но, увы, Selenoid все еще не серебряная пуля. Мы получили функцию ‘браузер по требованию’, но функция ‘ресурсы по требованию’ все еще не доступна. Для использования Selenoid мы должны развернуть его на физическом железе или на VM, что означает, что мы должны заранее знать, сколько ресурсов необходимо выделить. Я полагаю, это не проблема для маленьких проектов, которые запускают 10, 20 или даже 30 браузеров параллельно. Но что если нам нужно 100, 500, 1000 и больше? Не имеет никакого смысла поддерживать и платить за такое количество ресурсов постоянно. В секции 5 и 6 данной статьи мы обсудим решения, которые позволяют масштабироваться, тем самым значительно снижая расходы компании.

Selenoid for Android

После успеха Selenoid в качестве инструмента для web-автоматизации, люди хотели получить что-то подобное для Android. И это свершилось – Selenoid был выпущен с поддержкой Android. С высокоуровневой пользовательской точки зрения принцип работы аналогичен web-автоматизации. Единственное отличие заключается в том, что вместо контейнеров с браузерами Selenoid запускает контейнеры с Android-эмуляторами. На мой взгляд, на сегодняшний момент это самый мощный бесплатный инструмент для запуска Android-тестов параллельно.

Мне бы очень не хотелось говорить о негативных сторонах данного инструмента, так как он действительно мне очень нравится. Но все же тут присутствуют те же недостатки, относящиеся и к web-автоматизации, связанные с масштабированием. В дополнение к этому нужно рассказать о еще одном ограничении, которое может стать неожиданностью, если мы настраиваем инструмент впервые. Для запуска Android-образов нам необходима физическая машина или VM с nested virtualisation — поддержкой. В практическом руководстве я демонстрирую, как это активировать на Linux VM. Однако если вы являетесь macOS пользователем и хотите развернуть Selenoid локально, то для запуска Android-тестов это будет невозможно. Но вы всегда можете запустить Linux VM локально с настроенной ‘nested virtualisation’ и развернуть Selenoid внутри.

Иллюстрация текущего состояния инфраструктуры

В контексте этой статьи мы добавим 2 инструмента для иллюстрации инфраструктуры. Это Selenium grid для web-тестов и Selenoid для Android-тестов. В руководстве на GitHub я также покажу, как использовать Selenoid для запуска web-тестов.

Ссылки для изучения

Аналогичные инструменты

4. CI / CD

Краткое описание технологии

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

Итак, существуют 3 термина: CI — Continuous Integration (непрерывная интеграция), CD — Continuous Delivery (непрерывная поставка) и снова CD — Continuous Deployment (непрерывное развертывание). (Далее я буду использовать эти термины на английском языке). Каждая модификация добавляет несколько дополнительных этапов к вашему конвейеру разработки. Но слово continuous (непрерывная) является самым главным. В этом контексте мы подразумеваем что-то, что происходит от начала и до конца, без прерываний или ручного воздействия. Давайте посмотрим на CI & CD и CD в данном контексте.

Ценность для инфраструктуры автоматизации

В этом разделе я должен уточнить, что, когда мы говорим об end-to-end UI-тестах, это подразумевает, что мы должны разворачивать наши изменения и связанные сервисы на тестовых средах. Continuous Integration — процесс не применим для данной задачи и мы должны позаботиться о внедрении как минимум Continuous Deliver практик. Continuous Deployment также имеет смысл в контексте UI-тестов, если мы собираемся запускать их на production.

И перед тем как мы посмотрим на иллюстрацию изменения архитектуры, я хочу сказать несколько слов о GitLab CI. В отличие от других CI/CD-инструментов, GitLab предоставляет удаленный репозиторий и много других дополнительных функций. Таким образом, GitLab – это больше чем CI. Он включает из коробки управление исходным кодом, Agile управление, CI/CD pipelines, инструменты логирования и сборы метрик. Архитектура GitLab состоит из Gitlab CI/CD и GitLab Runner. Привожу краткое описание с официально сайта:

Gitlab CI/CD is a web application with an API that stores its state in a database, manages projects/builds and provides a user interface. GitLab Runner is an application which processes builds. It can be deployed separately and works with GitLab CI/CD through an API. For tests running you need both Gitlab instance and Runner.

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения

Аналогичные инструменты

5. Облачные платформы

Краткое описание технологии

«The public cloud is defined as computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them. They may be free or sold on-demand, allowing customers to pay only per usage for the CPU cycles, storage, or bandwidth they consume».

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

Ценность для инфраструктуры автоматизации

Какие конкретно ресурсы нам необходимы для end-to-end UI-тестов? В основном это виртуальные машины или кластеры (мы поговорим о Kubernetes в следующей секции) для запуска браузеров и эмуляторов. Чем больше браузеров и эмуляторов мы хотим запустить одновременно, тем больше CPU и памяти требуется и тем больше денег нам придется за это заплатить. Таким образом, публичные облака в контексте автоматизации тестирования позволяют нам запускать большое число (100, 200, 1000 …) браузеров/эмуляторов по требованию, получать результаты тестирования как можно быстрее и переставать платить за такие безумно ресурсозатратные мощности.

Самыми популярными облачными провайдерами являются Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). В практическом руководстве представлены примеры использования GCP, но в целом неважно, что именно вы будете использовать для задач автоматизации. Все они предоставляют примерно одинаковый функционал. Обычно для выбора провайдера руководство фокусируется на всей инфраструктуре компании и бизнес-требованиях, что за рамками данной статьи. Для инженеров по автоматизации будет интереснее сравнить использование облачных провайдеров с использованием облачных платформ конкретно для целей тестирования, таких как Sauce Labs, BrowserStack, BitBar и так далее. Так давай те же сделаем это! На мой взгляд, Sauce Labs является самой известной фермой облачного тестирования, поэтому я и взял ее для сравнения.

GCP против Sauce Labs для целей автоматизации:

Представим, что нам нужно прогнать одновременно 8 web-тестов и 8 Android-тестов. Для этого мы будем использовать GCP и запустим 2 виртуальные машины с Selenoid. На первой мы поднимем 8 контейнеров с браузерами. На второй – 8 контейнеров с эмуляторами. Давайте взглянем на цены:

Для запуска одного контейнера с Chrome, нам понадобится n1-standard-1 машина. В случае с Android это будет n1-standard-4 для одного эмулятора. На самом деле более гибкий и дешевый способ – это задание конкретных пользовательских значений для CPU/Memory, но в данный момент для сравнения с Sauce Labs это не принципиально.

А вот тарифы на использование Sauce Labs:

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

A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances terminate during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

И это все еще не конец! В действительности я уверен, что никто не запускает тесты по 12 часов без перерыва. И если это так, то вы можете автоматически запускать и останавливать виртуальные машины, когда они не нужны. Реальное время использования может снизиться до 6 часов в сутки. Тогда оплата в контексте нашей задачи уменьшится аж до 11$ в месяц за 8 браузеров. Разве это не прекрасно? Но с preemptible машинами мы должны быть осторожны и готовы к прерываниям и нестабильной работе, хотя эти ситуации могут быть предусмотрены и обработаны программно. Оно того стоит!

Но ни в коем случае я не говорю ‘никогда не используйте облачные тестовые фермы’. Они имеют ряд преимуществ. Прежде всего это не просто виртуальная машина, а полноценное решение для автоматизации тестирования с набором функционала из коробки: удаленный доступ, логи, скриншоты, видеозапись, различные браузеры и физические мобильные устройства. Во многих ситуациях это может быть незаменимой шикарной альтернативой. Особенно тестовые платформы полезны для IOS-автоматизации, когда публичные облака могут предложить только Linux/Windows-системы. Но разговор про IOS будет в следующих статьях. Я рекомендую всегда смотреть по ситуации и отталкиваться от задач: в каких-то дешевле и эффективнее использовать публичные облака, а в каких то тестовые платформы определено стоят потраченных денег.

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения

Аналогичные инструменты:

6. Оркестрация

Краткое описание технологии

У меня хорошие новости – мы почти достигли конца статьи! На данный момент наша инфраструктура автоматизации состоит из web и Android-тестов, которые мы запускаем через GitLab CI параллельно, используя инструменты с поддержкой Docker: Selenium grid и Selenoid. Более того, мы используем созданные через GCP виртуальные машины для поднятия в них контейнеров с браузерами и эмуляторами. Для уменьшения расходов мы запускаем этим виртуальные машины только по требованию и останавливаем, когда тестирование не проводится. Существует ли что-то еще, что может улучшить нашу инфраструктуру? Ответ – да! Встречаем Kubernetes (K8s)!

Для начала рассмотрим, как слова оркестрация, кластер и Kubernetes связаны между собой. На высоком уровне оркестрация – это система, которая разворачивает и управляет приложениями. Для автоматизации тестирования такими контейнеризируемыми (containerised) приложениями являются Selenium grid и Selenoid. Docker и K8s дополняют друг друга. Первый используется для развертывания приложений, второй – для оркестрации. В свою очередь K8s является кластером. Задача кластера использовать VMs в качестве Nodes, что позволяет устанавливать различный функционал, программы и сервисы в рамках одного сервера (кластера). Если какой либо из Node упадет, то подхватятся другие Nodes, что обеспечивает нашему приложению бесперебойную работу. В дополнение к этому K8s имеет важную функциональность, связанную с масштабированием (scaling), благодаря чему мы автоматически получаем оптимальное количество ресурсов, основываясь на нагрузке и установленных ограничениях.

По правде говоря, ручное разворачивание Kubernetes с нуля является совсем нетривиальной задачей. Я оставлю ссылку на известное практическое руководство «Kubernetes The Hard Way», и, если вам интересно, вы можете попрактиковаться. Но, к счастью, существуют альтернативные способы и инструменты. Самым легкий из них – использовать Google Kubernetes Engine (GKE) в GCP, что позволит получить готовый кластер после нескольких кликов. Для начала изучения я рекомендую использовать именно этот подход, так как он позволит вам сфокусироваться на изучении того, как использовать K8s для своих задач вместо исследования того, как внутренние компоненты должны быть между собой интегрированы.

Ценность для инфраструктуры автоматизации

Рассмотрим несколько значимых функций, которые предоставляет K8s:

Функция масштабирования является ключевой и может быть применена как к nodes внутри cluster node-pool, так и к pods внутри node. Существует 2 типа масштабирования, которые относятся как к nodes, так и pods. Первый тип – горизонтальный – масштабирование происходит за счет увеличения числа nodes/pods. Такой тип является более предпочтительным. Второй тип, соответственно, вертикальный. Масштабирование осуществляется за счет увеличения размеров nodes/pods, а не их количества.

Теперь рассмотрим наши инструменты в контексте вышеупомянутых терминов.

Как было упомянуто ранее, Selenium grid – очень популярный инструмент, и не сюрприз, что он был контейнеризирован (containerised). Следовательно, не вызывает удивление, что Selenium grid можно развернуть в K8s. Пример того, как это сделать, можно найти в официальном K8s-репозитории. Как обычно, прикладываю ссылки в конце секции. В дополнение к этому в практическом руководстве показано, как это сделать черед Terraform. Также есть инструкция, как масштабировать число pods, которые содержат контейнеры с браузерами. Но функция автоматического масштабирования в контексте K8s – все еще не до конца очевидная задача. Когда я начинал изучение, я не нашел никакого практического руководства или рекомендаций. После нескольких исследований и экспериментов при поддержке DevOps-команды мы выбрали подход поднятия контейнеров с нужными браузерами внутри одного pod, который находится внутри одного worker node. Такой способ позволяет нам применить стратегию горизонтального масштабирования nodes за счет увеличения их числа. Я надеюсь, что в будущем ситуация изменится, и мы увидим все больше и больше описаний лучших подходов и готовых решений, особенно после выпуска Selenium grid 4 с измененной внутренней архитектурой.

В настоящее время развертывание Selenoid в K8s является самым большим разочарованием. Они не совместимы. Теоретически мы можем поднять Selenoid-контейнер внутри pod, но когда Selenoid начнет запускать контейнеры с браузерами, они все еще будут находиться внутри этого же pod. Это делает scaling невозможным и, как результат, работа Selenoid внутри кластера не будет отличаться от работы внутри виртуальной машины. Конец истории.

Зная это узкое место при работе с Selenoid, разработчики выпустили более мощный инструмент, который назвали Moon. Этот инструмент был изначально задуман для работы с Kubernetes и, как результат, можно и нужно использовать функцию автомасштабирования. Более того, я бы сказал, что в настоящий момент это единственный инструмент в мире Selenium, который из коробки имеет native K8s cluster-поддержку (уже нет, см. следующий инструмент ). Ключевой особенностью Moon, которая обеспечивает данную поддержку, является:

Completely stateless. Selenoid stores in memory information about currently running browser sessions. If for some reason its process crashes — then all running sessions are lost. Moon contrarily has no internal state and can be replicated across data centers. Browser sessions remain alive even if one or more replicas go down.

Callisto: (Внимание! Этого нет в оригинальной статье и содержится только в русском переводе)

Как я и сказал, Selenium – очень популярный инструмент, а сфера IT развивается очень быстро. Пока я работал над переводом, в сети появился новый многообещающий инструмент Callisto (привет Cypress и другим убийцам Selenium). Он работает нативно с K8s и позволяет запускать Selenoid-контейнеры в pods, распределено по Nodes. Все работает сразу из коробки, включая автомасштабирование. Фантастика, но надо тестировать. Мне уже удалось развернуть данный инструмент и поставить несколько экспериментов. Но выводы делать рано, после получения результатов на длинной дистанции, возможно, я сделаю обзор в следующих статьях. Пока оставляю только ссылки для самостоятельных исследований.

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения

Аналогичные инструменты

7. Инфраструктура как код (IaC)

Краткое описание технологии

И вот мы подобрались к последнему разделу. Обычно, данная технология и связанные с ней задачи не входят в зону ответсвенности инженеров по автоматизации. И на это есть свои причины. Во-первых, во многих организациях инфраструктурные вопросы находятся под контролем DevOps отдела и команды разработки не особо заботятся о том, благодаря чему работает pipeline и каким образом нужно поддерживать все, что с ним связано. Во-вторых, будем честными, практика «Инфраструктура как код (IaC)» все еще не применяется во многих компаниях. Но определенно это стало популярным трендом и важно стараться быть вовлеченным в связанные с этим процессы, подходы и инструменты. Или, по крайней мере, быть в курсе событий.

Начнем с мотивации использования данного подхода. Мы уже обсудили, что для запуска тестов в GitlabCI нам понадобятся как минимум ресурсы для запуска Gitlab Runner. А для запуска контейнеров с браузерами/эмуляторами нам нужно зарезервировать VM или кластер. Помимо ресурсов для тестирования, нам необходимо значительное число мощностей для поддержания сред разработки, staging, production, что также включает базы данных, автоматические расписания, конфигурации сети, балансировщик нагрузки, права пользователей и так далее. Ключевая проблема заключается в требуемых усилиях для поддержки этого всего. Есть несколько способов того, как мы можем вносить изменения и выкатывать обновления. Например, в контексте GCP мы можем использовать UI-консоль в браузере и выполнять все действия, кликая кнопки. Альтернативным способом может быть использование API-вызовов для взаимодействия с облачными сущностями или применение утилиты командной сроки gcloud для выполнения нужных манипуляций. Но при действительно большом количестве различных сущностей и инфраструктурных элементов становится тяжело или даже невозможно выполнять все операции вручную. Более того, все эти ручные действия неконтролируемые. Мы не можем отправить их на review перед выполнением, использовать систему контроля версий и быстро откатить правки, которые привели к инциденту. Для решения таких проблем инженеры создавали и создают автоматические bash/shell-скрипты, что ненамного лучше предыдущих способов, так как их не так уж и легко быстро прочесть, понять, поддерживать и модифицировать в процедурном стиле.

В этой статье и практическом руководстве я использую 2 инструмента, относящихся к практике IaC. Это Terraform и Ansible. Некоторые полагают, что не имеет смысла использовать их одновременно, так как их функционал схож и они взаимозаменяемые. Но дело в том, что изначально перед ними ставятся совершенно разные задачи. И факт того, что эти инструменты должны дополнять друг друга, был подтвержден на совместной презентации разработчиками, представляющими компании HashiCorp и RedHat. Концептуальная разница заключается в том, что Terraform – это provisioning-инструмент для управления самими серверами. В то время как Ansible является инструментом управления конфигурациями, задачей которого является установка, настройка и управление софтом на этих серверах.

Еще одной ключевой отличительной особенностью данных инструментов является стиль написания кода. В отличие от bash и Ansible, Terraform используют декларативный стиль, основанный на описании желаемого конечного состояния, которого необходимо достичь в результате выполнения. Например, если мы собираемся создать 10 VMs и применить изменения через Terraform, то мы получим 10 VMs. Если применить скрипт еще раз, ничего не произойдет, так как у нас уже есть 10 VMs, и Terraform знает об этом, поскольку он хранит текущее состояние инфраструктуры в state-файле. А вот Ansible использует процедурный подход и, если попросить его создать 10 VMs, то на первом запуске мы получим 10 VMs, аналогично с Terraform. Но после повторного запуска у нас уже будет 20 VMs. В этом и заключается важное отличие. В процедурном стиле мы не храним текущее состояние и просто описываем последовательность шагов, которые должны быть выполнены. Разумеется, мы можем обработать различные ситуации, добавить несколько проверок на существование ресурсов и текущее состояние, но нет смысла тратить наше время и прикладывать усилия на контролирование данной логики. К тому же это увеличивает риск совершить ошибки.

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

Ценность для инфраструктуры автоматизации

Здесь важно понимать лишь то, что инфраструктура автоматизации тестирования должна рассматриваться как часть всей инфраструктуры компании. А это значит, что все IaC-практики должны быть применены глобально к ресурсам всей организации. Кто за это ответственен, зависит от ваших процессов. DevOps-команда более опытна в данных вопросах, они видят всю картину происходящего. Однако QA-инженеры сильнее вовлечены в процесс построения автоматизации и структуру pipeline, что позволяет им лучше видеть все требуемые изменения и возможности для улучшения. Самый лучший вариант – это работать сообща, обмениваться знаниями и идеями для достижения ожидаемого результата.

Приведу несколько примеров использования Terraform и Ansible в контексте автоматизации тестирования и инструментов, которые мы обсуждали до этого:

1. Описать через Terraform необходимые характеристики и параметры VMs и кластеров.

2. Установить с помощью Ansible необходимые для тестирования инструменты: docker, Selenoid, Selenium Grid и загрузить нужные версии браузеров/эмуляторов.

3. Описать через Terraform характеристики VM, в которой будет запущен GitLab Runner.

4. Установить с помощью Ansible GitLab Runner и необходимые сопутствующие инструменты, задать настройки и конфигурации.

Иллюстрация текущего состояния инфраструктуры

Ссылки для изучения:

Аналогичные инструменты

Подведем итоги!

Mind map диаграммы: эволюция инфраструктуры

step5: Cloud Platforms

Что дальше?

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

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

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

Из заголовка видно, что это была только первая часть. Несмотря на то, что она получилось довольно большой, здесь все еще не раскрыты важные темы. Во второй части я планирую рассмотреть инфраструктуру автоматизации в контексте IOS. Из-за ограничений Apple, связанных с запусками IOS симуляторов только на macOS системах, наш набор решений сужен. Например, мы лишены возможности использовать Docker для запуска симулятора или публичных облаков для запуска виртуальных машин. Но это не означает, что нет других альтернатив. Я постараюсь держать вас в курсе передовых решений и современных инструментов!

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

И напоследок. В будущем я планирую выпустить видео курс по построению тестовой инфраструктуры и популярным инструментам. В настоящее время в интернете довольно много курсов и лекций по DevOps, но все материалы представлены в контексте разработки, но не автоматизации тестирования. В этом вопросе мне очень нужна обратная связь, будет ли такой курс интересен и ценен для сообщества тестировщиков и автоматизаторов. Заранее спасибо!

Источник