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

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

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

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

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

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

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

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

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

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

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

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

Возможность ветвления в системах контроля версий была создана в основном для обеспечения параллельной работы разработчиков над разными частями проекта без риска, что кто-то из них сможет внести изменения, дестабилизирующие основную ветку (иногда ее называют мастером или главной линией), или добавит в нее ошибки [86].