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

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

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

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

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

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

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

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

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

— Какие инженеры нужны в твоей команде? Вряд ли любой разработчик сможет разрабатывать инструменты?

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

— Раз уж мы заговорили о пользователях, как ты убеждаешь людей применять твои инструменты?

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

— А тебе когда-нибудь попадались инструменты, которые только мешали работе или приносили больше вреда, чем пользы?