Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Извлеченный урок. Запуск одного и того же набора тестов в продакшене и в ходе непрерывной интеграции на этапе после фиксации (с недавно созданными двоичны- ми файлами, но с теми же действующими службами) — это очень недорогой способ изолировать сбои. Остающиеся сложности. В дальнейшем нагрузка, связанная с тестированием «всего кода в Google» (конечно, это преувеличение, потому что большинство проблем с про- дуктами решаются соответствующими командами), будет расти по мере интеграции Takeout с большим количеством продуктов и усложнения этих продуктов. Сравнение вручную результатов тестирования на этапе непрерывной интеграции и в продакшене будет требовать все больше затрат времени наблюдающего за сборкой. Улучшения в будущем. Открывается интересная возможность попробовать гер- метичное тестирование с записью и воспроизведением в непрерывной интеграции после фиксации. Теоретически это может помочь устранить сбои, вызванные API сторонних служб, что сделало бы набор тестов более стабильным и эффективным для обнаружения сбоев в течение двух часов после добавления изменений в Takeout, что является его предполагаемой целью. Сценарий 4: сохранение набора тестов зеленым Проблема: платформа поддерживала все больше плагинов сторонних продуктов, каждый из которых включает свои сквозные тесты, завершающиеся неудачей, по- этому весь комплект сквозных тестов почти всегда терпел неудачу. Не все сбои можно быстро исправить. Многие из них были обусловлены ошибками в двоичных файлах плагинов, которые команда Takeout не контролирует. Кроме того, некоторые ошибки важнее других: малозначительные ошибки и ошибки в коде тестов не долж- ны блокировать выпуск новых версий, тогда как более значимые ошибки должны останавливать этот процесс. Команда может отключать тесты, закомментировав их, но тогда ошибки будет слишком легко забыть. Один из типичных источников ошибок — развертывание новых функций в плагинах сторонних продуктов. Например, функция загрузки списка воспроизведения для плагина YouTube может быть включена для тестирования в среде разработки в те- чение нескольких месяцев, прежде чем будет добавлена в продакшен-версию. Тесты Takeout знали только об одном результате для проверки, поэтому часто приходилось 494 Глава 23. Непрерывная интеграция отключать их в некоторых средах и настраивать вручную по мере развертывания новых функций. Что предприняла команда. Команда придумала способ отключения неудачных тестов, отмечая их соответствующей ошибкой и отправляя уведомление соответ- ствующей команде (обычно команде, занимающейся разработкой плагина). Когда тест, отмеченный ошибкой, терпел неудачу, среда тестирования Takeout подавляла его. Это позволило набору тестов оставаться зеленым и давать уверенность, что все остальное, кроме известных проблем, работает как ожидается (рис. 23.4). % отключенных % успешных % зеленых Рис. 23.4. Сохранение набора тестов зеленым за счет (ответственного) отключения тестов Для решения проблемы команда добавила для инженеров плагинов возможность указывать имя флага новой функции или идентификатор изменения в коде, который активировал конкретную функцию вместе с ожидаемым результатом, как с функцией, так и без нее. В тесты была добавлена возможность отправки запросов в тестовую среду, чтобы определить, включена ли в ней данная функция, и соответствующим образом проверить ожидаемый результат. По мере накопления тестов, отключенных из-за ошибок и давно не обновлявших- ся, команда выполняла их автоматическую очистку. После очистки тесты вновь проверяли, была ли ошибка закрыта, запрашивая нашу систему ошибок. Если тест с отметкой об ошибке выполнялся успешно дольше некоторого установленного предела времени, то предлагалось сбросить отметку (и пометить ошибку как ис- правленную, если это еще не сделано). В этой политики было одно исключение: нестабильные тесты. Такие тесты команда могла отметить как нестабильные, чтобы система не предлагала сбросить отметку «нестабильный» на этапе очистки, если тест выполняется успешно. Эти изменения сделали набор тестов практически самоподдерживаемым (рис. 23.5). Извлеченный урок. Отключение тестов, сообщающих об ошибках, которые нельзя исправить немедленно, — это практический подход к сохранению набора тестов Непрерывная интеграция в Google 495 зеленым и дающим уверенность, что никакие сбои не будут забыты. Кроме того, автоматизация обслуживания набора тестов, включая управление оповещением и отслеживанием исправленных ошибок, поддерживает чистоту набора и предотвра- щает технический долг. На языке DevOps мы могли бы назвать метрику (рис. 23.5) MTTCU (mean time to clean up — среднее время на очистку). Дни Рис. 23.5. Среднее время устранения ошибки после фиксации Улучшения в будущем. Следующим полезным шагом могла бы стать автоматизация регистрации ошибок. В настоящее время это все еще ручной и обременительный процесс. Как упоминалось выше, некоторые из наших крупных команд уже ее реа- лизовали. Сложности в будущем. Описанные сценарии — далеко не единственные проблемы непрерывной интеграции, с которыми столкнулся проект Takeout. Есть и другие проблемы, требующие решения. Например, мы упоминали трудность изоляции отказов, обусловленных вышестоящими службами, в разделе «Сложности непре- рывной интеграции» выше. Takeout продолжает сталкиваться с этой проблемой из-за редких сбоев, возникающих в вышестоящих службах, например когда обновление безопасности в потоковой инфраструктуре, используемой Takeout API «Загрузка папок на диске», нарушило расшифровку архива после развертывания в продакшене. Вышестоящие службы проходят свой этап опробования и тестирования, но нет простого способа с помощью непрерывной интеграции автоматически проверить их совместимость с Takeout после развертывания в продакшене. Первоначальное решение включало создание промежуточной среды непрерывной интеграции для тестирования двоичных файлов Takeout с предварительными версиями зависимостей. Однако этот подход оказался трудным в поддержке из-за дополнительных проблем совместимости между промежуточной и продакшен-версиями. 496 Глава 23. Непрерывная интеграция Но я не могу позволить себе организовать непрерывную интеграцию Возможно, вы думаете, что все, о чем рассказывалось, это хорошо, но у вас нет ни времени, ни денег, чтобы внедрить хоть что-то из этого. Мы готовы признать, что у Google больше ресурсов и возможностей для внедрения непрерывной интеграции, чем у типичного стартапа. Тем не менее многие из наших продуктов росли так быстро, что у них тоже не было времени на разработку системы непрерывной интеграции (по крайней мере, адекватной). Попробуйте подумать о цене, которую вы заплатили в своих проектах и организа- циях за проблемы, обнаруженные и решенные в ходе эксплуатации. Эти проблемы отрицательно сказываются не только на конечном пользователе или клиенте, но и на команде. Частое тушение пожаров в продакшене вызывает стресс и деморализует. Да, создание систем непрерывной интеграции обходится дорого, но это не всегда дополнительная цена, потому что непрерывная интеграция помогает сместить за- траты влево, на более ранний и более предпочтительный этап, уменьшить частоту и, следовательно, цену проблем, возникающих справа. Непрерывная интеграция дает более стабильный продукт и более благоприятную культуру разработки, в которой инженеры чувствуют себя увереннее и могут положиться на то, что «система» сама обнаружит проблемы, а они смогут сосредоточиться на развитии продукта, а не на исправлении ошибок. Заключение В этой главе мы описали наши процессы непрерывной интеграции и некоторые спо- собы их автоматизации, но это не означает, что они идеальны. В конце концов, сама по себе система непрерывной интеграции — это всего лишь ПО, которое никогда не бывает достаточно полным, и его приходится развивать в соответствии с растущими требованиями применения и инженеров, для которых она предназначена. Мы по- пытались проиллюстрировать это развитие на примере проекта Takeout и показали возможные улучшения в будущем. Итоги y Система непрерывной интеграции решает, какие тесты использовать и когда. y Системы непрерывной интеграции становятся все более необходимыми по мере роста и развития кодовой базы. y Система непрерывной интеграции должна использовать более быстрые и на- дежные тесты на этапе предварительной проверки и более медленные и менее детерминированные тесты на этапе проверки после фиксации. y Доступная и полезная обратная связь позволяет системе непрерывной интеграции стать более эффективной. ГЛАВА 24 Непрерывная поставка Авторы: Радха Нараян, Бобби Джонс, Шери Шипе и Дэвид Оуэнс Редактор: Лиза Кэри Учитывая, насколько быстро и непредсказуемо меняется технологический ланд- шафт, конкурентное преимущество любого продукта заключается в его способности быстро выйти на рынок. Скорость выпуска продукта является критическим фак- тором конкурентной способности организации, качества ее продуктов и услуг и ее способности адаптироваться к новым правилам. Но эта скорость ограничивается временем развертывания. Развертывание редко завершается успехом при первом запуске. Среди преподавателей есть поговорка, что ни один план урока не пережи- вает первого контакта со студентами. Точно так же ни одно ПО не работает идеально при первом запуске, и единственная гарантия дальнейшего успеха — возможность быстро обновить ПО. Очень быстро. Работа над ПО с долгим сроком службы требует быстрого изучения новых идей, быстрого реагирования на изменение ландшафта или пользовательские проблемы, а также обеспечения высокой скорости разработки в масштабе. Как рассказывает Эрик Раймонд (Eric Raymond) в эссе «The Cathedral and the Bazaar» и Эрик Рис в книге «Бизнес с нуля» 1 , ключ к долгосрочному успеху любой организации всегда заключался в ее способности быстро воплощать идеи на практике и быстро реагиро- вать на отзывы пользователей. Мартин Фаулер (Martin Fowler) в статье «Continuous Delivery» ( https://oreil.ly/B3WFD ) указывает, что «самый большой риск для любого ПО заключается в создании чего-то бесполезного. Чем раньше и чаще вы будете передавать действующее ПО реальным пользователям, тем быстрее вы получите обратную связь и узнаете, насколько оно действительно ценно». Работа, которая продолжается долгое время, прежде чем начинает приносить пользу пользователям, сопряжена с высоким риском и высокой стоимостью и даже может подорвать моральный дух команды. Мы в Google стремимся выпускать продукты и их новые версии как можно раньше и чаще, чтобы команды могли быстро увидеть результаты своей работы и быстрее адаптироваться к меняющимся условиям рынка. Код приобретает ценность не во время разработки, а когда становится доступным 1 Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес- модели. М.: Альпина Паблишер, 2018. — Примеч. пер. 498 Глава 24. Непрерывная поставка пользователям. Сокращение времени между завершением разработки кода и появле- нием обратной связи от пользователей минимизирует стоимость продолжающейся работы. Вы добиваетесь выдающихся результатов, осознав, что запущенный проект никогда не завершится, и с его запуском вы начинаете цикл обучения, в ходе которого исправляете что-то очень важное, оцениваете результат, исправляете что-то следующее и т. д. — этот процесс не имеет конца. Дэвид Уикли, бывший менеджер по продуктам в Google Методы, которые мы описываем в этой книге, позволяют сотням (а в некоторых случаях тысячам) инженеров Google быстро устранять проблемы, параллельно работать над новыми функциями, не заботясь о выпуске новой версии, и ис- следовать эффективность новых функций с помощью A/B-тестирования. В этой главе основное внимание уделено ключевым рычагам, способствующим быстрому внедрению инноваций, а именно управлению рисками, масштабированию скоро- сти разработки и оценке компромиссов между стоимостью и ценностью каждой созданной функции. Идиомы непрерывной поставки в Google Основной принцип непрерывной поставки, а также методологии гибкой разработки заключается в том, что со временем меньшие пакеты изменений будут давать более высокое качество. Другими словами, чем быстрее, тем безопаснее. На первый взгляд это утверждение может показаться противоречивым, особенно если механизмы и условия, необходимые для внедрения непрерывной поставки, — например, непре- рывная интеграция и тестирование — еще не созданы. Для реализации идеальной системы непрерывной поставки может потребоваться время, поэтому мы сначала разрабатываем ее аспекты, которые независимо друг от друга приносят пользу на пути к конечной цели. Вот некоторые из них: Гибкость Частый выпуск изменений небольшими порциями. Автоматизация Уменьшение или устранение повторяющихся накладных расходов из-за частых выпусков. Изоляция Стремление к модульной архитектуре, чтобы изолировать изменения и упростить устранение неполадок. Надежность Измерение ключевых показателей работоспособности, таких как сбои или за- держки, и их улучшение. Скорость — это командная победа: как разделить процесс развертывания на управляемые этапы 499 Принятие решений на основе данных Использование A/B-тестирования показателей работоспособности. Поэтапное внедрение Развертывание изменений для нескольких пользователей перед открытием пол- ного доступа к этим изменениям. На первый взгляд частый выпуск новых версий ПО может показаться рискованным делом. С увеличением числа пользователей могут возникнуть опасения их негатив- ной реакции, если они обнаружат какие-то ошибки, оставшиеся незамеченными при тестировании, например из-за слишком большого объема нового кода в продукте, чтобы его можно было полностью протестировать. Но именно здесь может помочь непрерывная поставка. В идеале между выпусками должно вноситься достаточно мало изменений, чтобы потом легко можно было устранить неполадки. При использовании непрерывной поставки каждое изменение проходит через конвейер контроля качества и автоматически внедряется в производство. Во многих командах это не является практической реальностью, поэтому в качестве промежуточного шага часто прово- дится работа по изменению культуры разработки с целью внедрения непрерывной поставки, в ходе которой команды могут повысить свою готовность к развертыванию в любое время и укрепить свою уверенность в возможности в будущем выпускать новые версии чаще. Скорость — это командная победа: как разделить процесс развертывания на управляемые этапы В небольших командах изменения в кодовую базу вносятся с определенной ско- ростью. Мы наблюдали появление антипаттерна, сопровождающего укрупнение с последующим разделением команды на подгруппы: подгруппа ответвляет свой код, чтобы никому не наступать на ноги, а затем борется с интеграцией и ищет источники проблем. Мы в Google предпочитаем, чтобы команды продолжали развивать общую базу коду и автоматизировали тестирование, непрерывную интеграцию, разверты- вание и поиск источников проблем для быстрого их выявления (глава 23). Одна из наших самых больших баз кода — YouTube — представляет собой большое монолитное приложение на Python. Процесс выпуска новых версий этого приложе- ния очень трудоемок, и в нем участвуют специалисты по сборке, менеджеры по вы- пуску и другие добровольцы. Почти в каждую версию этого приложения включается несколько тщательно отобранных изменений или исправлений. Существует также 50-часовой цикл регрессионного тестирования вручную, выполняемый удаленной командой контроля качества для каждого выпуска. Когда издержки на выпуск так высоки, начинает развиваться цикл ожидания выхода новой версии, чтобы ее можно было еще немного потестировать. Между тем кто-то хочет добавить еще одну функ- цию, которая почти готова, и вскоре вы получаете трудоемкий, медленный и подвер- женный ошибкам процесс выпуска версии. Хуже всего, если эксперты, готовившие 500 Глава 24. Непрерывная поставка версии в последнее время, выгорят и покинут команду и никто не будет знать, как устранить странные сбои, возникающие при попытке выпустить обновление. Это может заставить вас паниковать только от одной мысли, что придется нажать на кнопку выпуска. Когда выпуск новых версий обходится слишком дорого и сопряжен с риском, ин- стинкт подсказывает, что нужно уменьшить частоту выпусков и увеличить период стабильности. Однако это дает лишь краткосрочное улучшение и со временем снижает скорость разработки и расстраивает команды и пользователей. Решение заключается в снижении затрат и повышении дисциплины, при этом очень важно сопротивляться очевидным операционным исправлениям и инвестировать в долго- срочные архитектурные изменения. Вот самые очевидные решения этой проблемы: возвращение к традиционной модели планирования, которая оставляет мало места для обучения или итераций, добавление более жесткого управления и надзора за процессом разработки, а также внедрение обзоров рисков или вознаграждение за добавление функций, часто малоценных, зато не несущих больших рисков. Однако наиболее выгодным вложением является переход на микросервисную архитектуру, которая даст большой группе разработчиков возможность делиться и оставаться инновационной, одновременно снижая риски. В некоторых случаях мы в Google переписывали приложение с нуля, а не просто переносили его в новую архитектуру. Любой из этих вариантов может занять месяцы и, вероятно, будет очень болезненным в краткосрочной перспективе, но эти затраты окупятся в течение не- скольких лет жизни приложения. Оценка изменений в изоляции: флаги управления функциями Ключ к надежным непрерывным выпускам версий — добавление «охранных флагов» ко всем изменениям. По мере развития продукта на разных этапах его разработки будет иметься несколько функций, сосуществующих в двоичном файле. Защитные флаги могут использоваться для управления этими функциями в продукте и уста- навливаться по-разному в сборках для выпуска и для разработки. Флаги, отключа- ющие функции, должны позволять инструментам сборки исключать такие функции из выпуска, если это позволяет язык. Например, стабильная функция, которая уже доставлена клиентам, может быть включена как для разработки, так и для выпуска. Разрабатываемая функция может быть включена только для разработки, чтобы защитить пользователей от не готовой к выпуску функции. Код новой функции на- ходится в двоичном файле вместе со старым кодом, и оба могут работать, но доступ к новому коду охраняется флагом. Если новый код работоспособен, вы сможете удалить старый код и открыть доступ к функции в следующем выпуске. Если есть проблема, значение флага можно обновить независимо от двоичной версии с по- мощью динамического обновления конфигурации. |