Книга: Руководство по DevOps

Внедрить методы разработки на базе основной ветки

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

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

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

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

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

Рассмотрев эти методы, мы можем теперь снова изменить определение состояния «сделано» (выделено жирным шрифтом): «В конце каждого интервала разработки мы должны иметь интегрированный, протестированный, рабочий и потенциально готовый к поставке (что демонстрируется запуском в среде, близкой к производственной) код, созданный на базе основной ветки процессом, “запускаемым одним щелчком мыши”, и проверенный автоматическими тестами».

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

Оглавление книги