Джин Ким - Руководство по DevOps

Как объясняет Блэнд, «команда 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 % от общего числа разработчиков).

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

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

На этом этапе мы создаем наборы автоматических тестов, обеспечивающие увеличение частоты интеграций и превращающие тестирование нашего кода и наших сред из периодических в непрерывные. Мы можем сделать это за счет создания конвейера развертывания, и он будет выполнять интеграцию нашего кода и сред и запускать серию тестов каждый раз, когда в систему контроля версий вносится новое изменение [75](рис. 13).