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

Практически у каждого из нас на работе есть служебный компьютер (за исключением людей, которые работают со своих ноутбуков). И этот служебный компьютер достаточно мощный для вашего типа работы. Если нет, то может вам задуматься о смене работы? 😉 Идея очень проста – вы большую часть времени не используете всю мощность вашего компьютера. Так почему бы не поделиться ей для внутренних задач?

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

Для ускорения нам понадобится Selenium Grid – продукт, разработанный для параллельного запуска тестов. На одном из выделенных серверов поднимается Grid Hub – специальный процесс, который управляет процессом координации тестов и контролирует поднятые процессы WebDriver. На всех рабочих машинах поднимается WebDriver в режиме работы с Grid Hub и подсоединяется к нему. Детальную инструкцию по подъему можно найти тут. При первом же запуске тестов вы увидите, что у кого-то из команды вдруг откроется браузер и начнет работать с тестом. Это не очень удобно. 🙂

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

Как работает такой подход? Теперь, при запуске тестов на любой машине в сети, все они будут передаваться на Grid Hub и распределяться по доступным процессам WebDriver/Selenium. Если в вашей команде 5-10 человек, то ждать завершения выполнения ваших тестов придется в несколько раз меньше, что позволит сократить время выполнения до десятков минут. Причем, ускорятся как контрольные прогоны на выделенных серверах, так и локальные прогоны. А представьте, сколько свободных мощностей есть у вас ночью! 🙂 Осталась самая малость – сделать тесты более-менее независимыми друг от друга. Но это уже другая история. 🙂

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

Я приведу пример из мира Java, но думаю, что подобный подход можно реализовать и в других языках программирования. На помощь нам приходит GridGain – фреймворк для построения распределенных вычислительных топологий в режиме реального времени. Уже давно в нем есть поддержка распределенного запуска модульных тестов. Для успешной операции на каждой машине нужно установить GridGain и убедиться, что включена топология автоматического обнаружения по локальной сети. Вторым шагом нужно пометить ваши тесты специальной аннотацией либо воспользоваться механизмом запуска тестов, встроенным в GridGain. И все! Работает все очень просто. Ваш скомпилированный код автоматически загружается на доступные машины и выполняются тесты. Результаты агрегировуются на машине, с которой тесты запускались. В итоге, вы получаете ускорение в разы практически без усилий.

Подведем итоги. Одна из самых больших проблем в разработке – ожидание. Мы ждем завершения тестов, компиляции, сборки и прочих внутренних задач. Это стоит команде и проекту очень дорого, потому что “простаивают” высокооплачиваемые сотрудники. Ставьте перед собой цель уменьшить продолжительность ожидания и используйте для этого все доступные средства. Это позволит вам работать быстрее и делать более качественные продукты. Удачи!

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!