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

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

Чтобы поддерживать конвейер развертывания в «зеленом» состоянии, создадим виртуальный шнур-андон, аналогичный физическому шнуру в системе производства Toyota. Когда кто-либо вносит изменение, нарушающее сборку или прохождение автоматизированных тестов, любая новая работа не подпускается в систему, пока проблема не устранена. И если кто-то нуждается в помощи для устранения этой проблемы, он может получить ее от всех членов команды, как и в примере с компанией Google, приведенном в начале главы.

Когда работа конвейера развертывания нарушена, мы по крайней мере должны уведомить о сбое всю команду, чтобы тот, из-за кого проблема возникла, мог ее исправить или откатить внесенные изменения. Мы даже можем настроить систему контроля версий для предотвращения дальнейшей записи изменений кода, пока первая стадия (то есть сборка и модульное тестирование) конвейера развертывания не перейдет обратно в «зеленое» состояние. Если эта проблема вызвана тем, что автоматизированная проверка выдала ложноположительную оценку, неправильная проверка должна быть переписана или удалена [84]. Каждый член команды должен быть наделен полномочиями для совершения отката, чтобы вернуть сборку обратно в «зеленое» состояние.

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

Когда на более поздних этапах конвейера развертывания, таких как приемочные испытания или тесты производительности, происходит сбой, мы вместо остановки новых работ собираем оперативно всех разработчиков и тестировщиков, несущих ответственность за немедленное устранение этих проблем. Они должны также создать новые тесты, выполняемые на более ранней стадии конвейера развертывания, чтобы отловить появление этих проблем при возможных регрессиях. Например, если мы обнаружим дефект в ходе приемочных испытаний, то должны написать модульный тест для раннего выявления проблемы. Аналогично, обнаружив дефект в ходе аналитического тестирования, мы должны написать модульный или приемочный тест.

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

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

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

• кто-то записал изменения кода, «ломающие» сборку или автоматизированные тесты, но никто не исправляет ошибку;

• кто-то еще записывает другое изменение в «сломанной» сборке, также не проходящее автоматизированные тесты — но никто не видит результатов проверки этого кода, а ведь они дали бы возможность увидеть новый дефект, не говоря уже о его исправлении;

• имеющиеся у нас тесты не работают надежно, и поэтому маловероятно, что мы будем создавать новые тесты (зачем, если мы и имеющиеся-то тесты не можем заставить работать!).

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

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

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

В предыдущей главе мы создали методы автоматизированного тестирования, чтобы обеспечить быстрое получение разработчиками обратной связи о качестве их труда. Это становится еще более важным по мере увеличения числа разработчиков и количества ветвей в системе контроля версий.