Джеймс Уиттакер - Как тестируют в Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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