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

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

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

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

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

Неожиданная широта проблем, решаемых с помощью непрерывной интеграции, а также сами решения подтверждены опытом Гэри Грювера, директора по проектированию компании HP LaserJet Firmware, создающей программное обеспечение для всех выпускаемых сканеров, принтеров и многофункциональных устройств.

Отдел состоял из четырех сотен разработчиков, находящихся в США, Бразилии и Индии. Несмотря на размер отдела, работа шла очень медленно. В течение ряда лет они были не в состоянии создать новые функциональные возможности так быстро, как это было необходимо для бизнеса.

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

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

• 20 % на подробное планирование (низкая производительность и длительное время релиза приводили к ошибочным оценкам, и в надежде получить более устраивающий ответ сотрудникам отдела предлагали оценить работу более подробно);

• 25 % занимало портирование кода, поддерживаемое в отдельных ветках;

• 10 % уходило на интеграцию кода, написанного разработчиками в разных филиалах;

• 15 % занимало завершение тестирования вручную.

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

• непрерывной интеграции и разработкой на базе основной ветки;

• значительных инвестиций в автоматизацию тестирования;

• созданием эмуляторов оборудования, чтобы тесты можно было запускать на виртуальных платформах;

• воспроизведением сбоев в ходе тестирования на рабочих станциях разработчиков;

• разработкой новой архитектуры для поддержки работы всех принтеров на общих сборках и версиях.

Раньше релиз новой линейки продуктов требовал создания новой ветки кода, а каждая модель имела уникальное встроенное ПО. Его возможности определялись во время компиляции [87]. Новая архитектура подразумевала, что все разработчики используют общую базу кода с единой версией встроенного программного обеспечения, поддерживающей все модели LaserJet, построенной из кода основной ветки, а особенности принтеров определяются во время выполнения из XML-файла конфигурации.

Четыре года спустя у них имелась одна база кода, поддерживающая все двадцать четыре продукта линеек HP LaserJet, разрабатываемая как в основной ветке. Грювер признавал, что разработка на основе основной ветки требует значительного изменения образа мыслей. Инженеры считали, что такой метод никогда не сможет работать, но после того, как начали его использовать, даже не помышляли вернуться к прежнему методу. За эти годы из HP уволились несколько инженеров, и они говорили, насколько устарела организация разработки в новых компаниях, как трудно быть эффективным и выпускать хороший код при отсутствии обратной связи, предоставляемой непрерывной интеграцией.

Однако разработка на базе основной ветки потребовала создания более эффективного автоматизированного тестирования. Грювер отмечал: «Без автоматического тестирования и непрерывной интеграции это оказывается самым быстрым способом получить большую кучу барахла. Оно никогда не скомпилируется или не будет работать правильно». Вначале цикл полного тестирования вручную требовал шести недель.

Чтобы иметь возможность автоматически протестировать все сборки микропрограмм, значительные средства вложили в эмуляторы принтеров и за шесть недель создали тестовые фермы — в течение нескольких лет две тысячи эмуляторов принтеров запускались на шести стойках с серверами и обрабатывали сборки микропрограмм, взятых из конвейера разработки. Их система непрерывной интеграции (CI) выполняла весь комплекс автоматизированного модульного, приемочного и интеграционного тестирования сборок, сделанных на базе основной ветки, как описано в предыдущей главе. Кроме того, создали культуру производства, останавливающую всю работу, как только кто-то из разработчиков повреждал конвейер развертывания. Так обеспечивался быстрый возврат системы в рабочее состояние.

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