Книга: Руководство по DevOps

Глава 10. Быстрое и надежное автоматизированное тестирование

Глава 10. Быстрое и надежное автоматизированное тестирование

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

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

Сейчас компания Google, несомненно, является примером внутренней производственной культуры, должным образом ценящей автоматизированное тестирование. Но такой подход соблюдался не всегда. В 2005 г., когда Майк Блэнд пришел на работу в компанию, развертывание обновлений сайта Google.com зачастую сопровождалось серьезными проблемами, особенно для команды Google Web Server (GWS).

Как объясняет Блэнд, «команда GWS попала в описанную выше ситуацию в середине 2000-х гг. Ей было чрезвычайно трудно внести изменения в веб-сервер — приложение на C++, обрабатывавшее все запросы к главной странице Google и многим другим веб-страницам сайта. При всей важности и известности Google.com работа в составе команды GWS была отнюдь не гламурным занятием — зачастую она напоминала поиски на свалке кода, реализующего различные функции, написанные командами, которые работали независимо друг от друга. Они сталкивались с такими проблемами, как слишком длительные сборка и тестирование кода, запуск в производство непротестированного кода, проходящая лишь изредка запись изменений кода, причем эти изменения вступали в противоречие с вносимыми другими командами».

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

Блэнд описывает, как сумел повлиять на разработчиков, развертывавших изменения: «Страх стал убийцей мышления. Страх перед изменениями останавливал новых членов команды, они не понимали, как работает система. Но страх останавливал также и опытных сотрудников, так как они очень хорошо понимали последствия»[73]. Блэнд был частью группы, решавшей эту проблему.

Руководитель команды GWS Бхарат Медиратта считал, что автоматизированное тестирование поможет решить проблему. Как описывает Блэнд, «они утвердили жесткую позицию: изменения не будут приняты в GWS, если они не прошли автоматизированное тестирование. Они настроили непрерывную сборку и буквально с религиозным упорством соблюдали это правило. Они организовали отслеживание уровня тестового покрытия и обеспечивали постоянный его рост с течением времени. Они дописали политику и руководства по тестированию и настаивали, чтобы все участники, связанные с этими процессами как внутри команды, так и вне ее, строго соблюдали установленные правила».

Результаты поразили воображение. Как отмечает Блэнд, «GWS быстро стала одной из самых продуктивных команд в компании, выполняя интеграционную сборку большого числа изменений, поступающих от разных команд каждую неделю, поддерживая при этом график быстрых релизов. Новые члены команды теперь почти сразу же начинали плодотворно работать, внося вклад в сложную систему благодаря хорошему покрытию кода тестами и его качеству. В итоге радикальная политика позволила главной странице сайта Google.com быстро расширить возможности, преуспев в стремительно меняющемся мире конкурирующих технологий».

Но GWS все же была относительно небольшой командой в крупной и растущей компании. Команда хотела распространить применяемые методы на всю организацию. Поэтому на свет появилась Testing Grouplet, неофициальная группа инженеров, желавших распространить автоматизированное тестирование во всей организации. В течение следующих пяти лет они помогли растиражировать культуру автоматического тестирования на все подразделения компании Google[74].

Теперь, когда любой разработчик компании выполняет запись изменений кода, сразу запускается набор из сотен тысяч автотестов. Если код проходит проверку, то он автоматически включается в основную ветку и оказывается готовым к развертыванию в производственной среде. Многие продукты Google собираются ежечасно или ежедневно, другие используют философию доставки Push on Green.

Ставки при таком подходе выше, чем когда бы то ни было: одна-единственная ошибка развертывания кода может одномоментно нарушить работу всего комплекса программ Google (например, из-за глобальных изменений в инфраструктуре или если дефект внесен в одну из основных библиотек, от которой зависит каждая программа).

Эран Мессери, инженер группы Google Developer Infrastructure, отмечает: «Время от времени случаются большие неудачи. Вы получаете кучу мгновенных сообщений, а инженеры стучатся в вашу дверь. Когда конвейер развертывания сломан, мы должны исправить это сразу, потому что разработчики не могут больше записывать изменения кода. Поэтому мы хотим сделать откат очень легким».

Эта система работает в компании Google благодаря профессионализму инженеров и культуре высокого доверия, предполагающей, что каждый хочет сделать свою работу хорошо и что мы можем быстро обнаруживать проблемы и исправлять их. Мессери объясняет: «В Google нет жестких правил, например “если вы вызовете остановку у более чем десяти проектов, то обязаны устранить проблему в течение десяти минут”. Вместо этого существует взаимное уважение между командами, подразумевается, что каждый делает все от него зависящее для поддержания конвейера развертывания. Все мы знаем, что однажды я могу нечаянно повредить ваш проект, а на следующий день вы можете сломать мой».

Результаты, полученные Майком Блэндом и командой Testing Grouplet, сделали компанию Google одной из самых продуктивных технологических организаций в мире. К 2013 г. автоматизированное тестирование и непрерывная интеграция позволили более чем 4000 независимых команд в компании работать вместе и оставаться продуктивными, одновременно выполняя разработку, непрерывную интеграцию, тестирование и развертывание своего кода в производственной среде. Весь код хранится в одном репозитории, он состоит из миллиардов файлов, и они постоянно используются для сборки и интеграции, причем ежемесячно код обновляется наполовину. Некоторые другие статистические данных об их производительности выглядят весьма внушительно:

• 40 000 записей изменений кода в день;

• 50 000 сборок в день (в выходные дни их число может превысить 90 000);

• 120 000 наборов автоматизированных тестов;

• 75 миллионов тестов выполняется ежедневно;

• свыше 100 инженеров, занимающихся разработкой тестов, непрерывной интеграцией и созданием инструментов для увеличения производительности труда разработчиков (что составляет 0,5 % от общего числа разработчиков).

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

Оглавление книги