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

• сокращают количество сборок до одной в день, что в конечном счете означает от десяти до пятнадцати сборок в день;

• переходят от примерно двадцати фиксаций кода в день, совершаемых «главным по сборкам», до свыше ста в день, совершаемых самими разработчиками;

• получают возможность изменять или добавлять до 75–100 тысяч строк кода каждый день;

• снижают длительность регрессионного тестирования с шести недель до одного дня.

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

• доля времени разработчиков, затраченного на инновации и написание новых функциональностей, возросла с 5 до 40 %;

• общая стоимость разработки была сокращена примерно на 40 %;

• количество программ, находящихся в разработке, увеличилось примерно на 140 %;

• расходы на разработку одной программы сократились на 78 %.

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

Как описано в предыдущих главах, когда в систему контроля версий вносятся изменения, нарушающие работу конвейера развертывания, мы быстро набрасываемся на проблему, чтобы ее исправить, в результате чего конвейер развертывания возвращается в «зеленое» состояние. Вместе с тем значительные проблемы появляются, если разработчики трудятся над долго существующими частными ветками (их еще называют «ветки функциональности»). Их обратное слияние с основной веткой выполняется нерегулярно, в результате чего список изменений оказывается весьма велик. Как показано на примере HP LaserJet, это приводит к хаосу и значительным переделкам, требующимся для приведения кода в состояние готовности к релизу.

Джефф Этвуд, основатель сайта Stack Overflow («Переполнение стека») и автор блога Coding Horror («Ужас кодирования»), отмечает, что, в то время как существует множество стратегий ветвления, все они могут быть поделены на две группы.

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

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

Мнение Этвуда абсолютно правильно, и если сформулировать точнее, то усилия, необходимые для успешного объединения веток, растут экспоненциально по мере роста числа веток. Проблема заключается не только в объеме переделок, необходимых после «ада слияний», но также в том, что обратную связь от конвейера развертывания мы получаем с задержкой. Например, скорее всего, только в конце процесса разработки удастся выполнить тестирование производительности полностью интегрированной системы — непрерывным данный процесс сделать не получится.

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

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

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

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

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

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