Как тестируют в Google - Уиттакер .

Интервью с директором разработки инженерных инструментов Ашишем Кумаром

Инструменты — вопрос жизни и смерти для Google. Ашиш Кумар — это человек, который отвечает за разработку инструментов. В его зоне ответственности находится весь чемодан внутренних инструментов Google: от IDE, в которых пишут разработчики, до систем код-ревью, от инструментов сборки, контроля исходного кода и статического анализа до общей тестовой инфраструктуры — за все отвечает он. Даже команды Selenium и WebDriver отчитываются перед Ашишем.

Мы встретились с Ашишем, чтобы узнать об этой части Google поподробнее.

— Область автоматизации в Google кажется чем-то магическим, во многом благодаря GTAC, а ты — человек, который за всем этим стоит. Приоткрой нам завесу тайны, какие возможности предоставляет твой инструментарий инженерам Google?

Ашиш: Команда разработки инженерных инструментов, а именно так мы называемся, отвечает за создание 90% инструментов, ежедневно используемых разработчиками Google, когда они пишут, собирают и выпускают качественные приложения. Последние 10% мы охватим, когда сможем поддерживать все команды, работающие с открытым кодом.

Google уникален тем, что огромное внимание уделяется созданию мощной и масштабируемой инфраструктуры для разработчиков. Люди извне обычно знакомы с технологиями MapReduce и BigTable, которые наши разработчики постоянно используют. Но наша внутренняя инфраструктура для разработки — это тоже большая часть нашей работы.

— Можно конкретнее?

Ашиш: Ладно, сами напросились! Набор инструментов включает:

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

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

— Инфраструктура сборки. Эта система позволяет нам распределить сборку мультиязычного кода по десяткам тысяч процессоров, используя такие объемы памяти и дискового пространства, что мне даже представить страшно! Система сборки работает как для интерактивного, так и для автоматизированного использования. Она формирует результаты за секунды, хотя та же работа в другом случае занимала бы часы.

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

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

— Метрики, графики и отчеты. Здесь речь об управлении багами по всем продуктам Google, сборе и хранении метрик разработки, тестирования и выпусков. Наша задача — предоставлять командам обратную связь, чтобы они могли улучшить свою работу.

— Значит, ты одновременно работаешь на всех фронтах. Чтобы достичь такого успеха, вы наверняка добавили много инноваций в рабочий процесс. Как вам удается сохранять баланс между новыми разработками и профильной работой? Ведь твоя команда не такая уж большая.

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

Мы много экспериментируем. Чтобы добиться большого успеха в следующем году, нужно работать уже сейчас, поэтому несколько небольших команд по одному-два человека всегда работают над экспериментами. Часто опыты проходят в «двадцатипроцентное» время, и я не против, так как это личное время инженеров, которым они вольны распоряжаться. Разумеется, часть экспериментов провалится, но те, которые приведут к успеху, с лихвой компенсируют любые неудачи. Мечтайте о большом, быстро понимайте, если идете не туда, и не сдавайтесь!

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

— А была ли идея, которая казалась тебе неудачной, но привела к успеху?

Ашиш: Да! Масштабная непрерывная интеграция. Она казалась недостижимой, потому что требовала огромного объема работы. Тогда у нас были тысячи машин, которые непрерывно выполняли циклы интеграции для каждого проекта. Кто-то предложил создать инфраструктуру, которая сделала бы этот процесс централизованным для всего Google. Такая инфраструктура опрашивала бы системы управления кодом на предмет изменений, держала бы в памяти огромный граф мультиязычных зависимостей этих изменений, а потом автоматически собирала бы и запускала нужные тесты. Многие скептически относились к проекту, так как идея была слишком масштабна и наши серверы могли не потянуть. Я тоже был среди скептиков: решение требовало огромного количества ресурсов. Но шаг за шагом наши инженеры понемногу преодолевали технические трудности до тех пор, пока не добились успеха: система запущена и работает. Собственно, это и есть схема нашей работы с проектами: начинаем с малого, а если практическая польза и потенциал доказаны, разворачиваемся на полную.

— А есть ли инструмент, который обещал быть успешным, но провалился?

Ашиш: Снова да! Удаленное парное программирование. В Google много распределенных команд. Многие команды применяют парное программирование и другие гибкие методы разработки. Часто бывает, что вы работаете над кодом, который написал человек из другого офиса, и если у вас появляются вопросы, то возникает задержка, влияющая на производительность.

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

К сожалению, опробовав тестовую версию только с простым совместным редактором без интеграции с Google Talk, мы свернули проект. Статистика использования не дала ожидаемых результатов, показала, что разработчики не заинтересованы в продукте. Может быть, мы переоценили важность проблемы.

— Твой совет компании, которая хочет построить непрерывный процесс автоматизации? С каких инструментов стоит начать?

Ашиш: Самое важное — создать такую среду разработки, чтобы в ней даже разработчик-новичок смог работать с вашей командой. Должно быть невероятно просто взять код из репозитория, отредактировать, протестировать, отладить его и опубликовать. Если вы сформируете настолько удобную среду, то все ваши разработчики будут работать более продуктивно и вы сможете выпускать ваше ПО без задержек.

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