Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Практический пример

Непрерывная интеграция в компании Bazaarvoice (2012 г.)

Эрнест Мюллер, помогавший производить DevOps-трансформацию в компании National Instruments, позже, в 2012 г., занимался преобразованием процессов разработки и релиза ПО в компании Bazaarvoice. Она обеспечивала обработку пользовательского контента (например, обзоры, рейтинги) для тысяч предприятий розничной торговли, в том числе Best Buy, Nike и Walmart.

В то время Bazaarvoice имела 120 миллионов долларов дохода и готовилась к IPO[88]. Основным источником прибыли компании было приложение Bazaarvoice Conversations — монолитное приложение на языке Java, состоявшее из почти пяти миллионов строк кода, написанных начиная с 2006 г. и содержавшихся в 15 тысячах файлов. Оно работало на 1200 серверах в четырех центрах обработки данных с использованием нескольких поставщиков облачных услуг.

В компании, частично в результате перехода на Agile-процесс и двухнедельный цикл разработки, появилось сильное стремление увеличить частоту релизов по сравнению с действовавшим планом релиза версий каждые десять недель. Сотрудники также приступили к разделению частей монолитного приложения, разбивая его на микросервисы.

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

Мюллер стал руководить процессом релиза. Он поставил целью делать релизы каждые две недели, не допуская простоев при обслуживании клиентов. В бизнес-цели увеличения частоты релизов входило использование более быстрого A/B-тестирования (описано в следующих главах) и увеличение скорости выпуска нового функционала. Мюллер определил три основные проблемы:

• недостаточная автоматизация тестирования на любом уровне тестирования в течение двухнедельного интервала не дает возможности предотвратить крупномасштабные сбои;

• стратегия ветвлений системы контроля версий позволяет разработчикам проверить новый код только почти непосредственно перед релизом;

• команды, работающие над микросервисами, делали релизы независимо, что нередко вызывало проблемы с монолитной версией, и наоборот.

Мюллер пришел к выводу: процесс развертывания монолитного приложения Conversations необходимо стабилизировать, что требует введения непрерывной интеграции. В течение следующих шести недель разработчики прекратили добавление новых функциональных возможностей, вместо этого сосредоточившись на написании наборов автоматизированного тестирования, включая модульное тестирование в JUnit, регрессивное тестирование в Selenium, и запустив работу процесса развертывания в TeamCity. «Все время выполняя эти тесты, мы почувствовали, что можем вносить изменения относительно безопасно. И самое главное, мы смогли бы сразу же обнаружить, когда нечто повреждало что-то, тогда как раньше обнаруживали это только после запуска в производство».

Они также перешли на релиз кода на базе основной ветки. Каждые две недели создавали новую специальную ветку, но затем в ней не разрешалось, кроме самых крайних случаев, делать никаких новых изменений кода: все изменения обрабатывались при выходе из процесса, или по заданию на работу, или внутри команд через их внутренние wiki. Эта ветка проходила тестирование, а затем передавалась в производство.

Увеличение предсказуемости и улучшение качества релизов оказались поразительными:

• релиз в январе 2012 г.: 44 обращения о сбоях от клиентов (начаты усилия по внедрению постоянной интеграции);

• релиз 6 марта 2012 г.: спустя пять дней — пять обращений о сбоях от клиентов;

• релиз 22 марта 2012 г.: сделан вовремя, одно обращение от клиента;

• релиз 5 апреля 2012 г.: сделан вовремя, обращений от клиентов нет.

Позже Мюллер описывал, насколько успешными оказались усилия:

«Мы добились такого успеха с релизами каждые две недели, что решили перейти на еженедельные релизы, что не требовало почти никаких изменений в инженерных командах. Поскольку релизы стали рутинным делом, было очень просто удвоить их количество в календарном плане и делать их тогда, когда об этом напоминал календарь. Действительно, это происходило практически без каких-то значимых событий. Большинство необходимых изменений делались в командах клиентского обслуживания и маркетинга. Они должны были вносить изменения в свои процессы, такие как изменение расписания еженедельных сообщений клиентам, какие изменения в функциях будут произведены. После этого мы начали работать над достижением следующих целей, в итоге приведших к уменьшению времени на тестирование с трех с лишним часов до менее часа, сокращению количества сред с четырех до трех (среда для разработки, для тестирования, производственная среда, а среда для завершающего тестирования была исключена) и переходу к полной модели непрерывной доставки, чтобы мы могли выполнить развертывание быстро, одним щелчком мыши».