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

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

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

Рассмотрев эти методы, мы можем теперь снова изменить определение состояния «сделано» (выделено жирным шрифтом): «В конце каждого интервала разработки мы должны иметь интегрированный, протестированный, рабочий и потенциально готовый к поставке (что демонстрируется запуском в среде, близкой к производственной) код, созданный на базе основной ветки процессом, “запускаемым одним щелчком мыши”, и проверенный автоматическими тестами».

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

Эрнест Мюллер, помогавший производить 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 г.: сделан вовремя, обращений от клиентов нет.

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

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

Разработка на базе основной ветки — наиболее спорный метод из описанных. Многие инженеры не считают это возможным, среди них есть даже те, кто предпочитает работать над своей веткой, не отвлекаясь на другие и не имея дел с другими разработчиками. Однако данные из доклада 2015 State of DevOps Report компании Puppet Labs ясно показывают: разработка на базе основной ветки предсказывает более высокую производительность, лучшую стабильность и даже более высокую удовлетворенность разработчиков своей работой и меньшую вероятность появления у них эмоционального истощения.