Магистральная разработка

Преимущества магистральной разработки

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

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

Непрерывная интеграция кода

Модель магистральной разработки предполагает наличие репозитория со стабильным потоком коммитов, которые поступают в основную ветку. Непрерывная интеграция достигается путем добавления набора автоматизированных тестов и мониторинга покрытия кода для этого потока коммитов. После слияния нового кода с магистралью выполняется проверка его качества. Для этого запускаются автоматизированные тесты по интеграции и покрытию кода.

Непрерывная проверка кода

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

Последовательные релизы кода в рабочую среду

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

Магистральная разработка и CI/CD

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

Рекомендации по магистральной разработке

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

Разрабатывайте небольшими пакетами

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

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

Флажки функции

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

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

Внедряйте комплексное автоматическое тестирование

Автоматическое тестирование необходимо для любого современного проекта разработки по методологии CI/CD. Существуют различные типы автоматических тестов, которые выполняются на разных этапах конвейера релизов. Краткосрочные модульные и интеграционные тесты выполняются в процессе разработки и после слияния кода. Более длительные и комплексные сквозные тесты выполняются на более поздних этапах конвейера на основе всего раздела проиндексированных файлов или рабочей среды.

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

Выполняйте асинхронные проверки кода

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

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

После слияния ветки ее рекомендуется удалить. Репозиторий с большим количеством активных веток имеет ряд неприятных побочных эффектов. Командам может быть полезно узнавать по активным веткам, какая работа ведется, однако при наличии устаревших и неактивных веток эта возможность исчезает. Некоторые разработчики используют пользовательские интерфейсы Git, которые при загрузке большого количества удаленных веток начинают работать медленно.

Выполняйте слияние в магистральную ветку не реже раза в день

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

Сократите количество запретов на изменение кода и этапы интеграции

В командах, следующих принципам Agile и практикующих непрерывную интеграцию и непрерывную поставку, не должно возникать необходимости в плановых запретах на изменения кода или в перерывах на этапе интеграции, хотя организация может использовать эти механизмы по другим причинам. В CI/CD принцип «непрерывности» подразумевает, что обновления выполняются постоянно. Команды, ведущие магистральную разработку, должны по возможности избегать запретов на изменения кода, которые останавливают все процессы, и планировать свою работу так, чтобы конвейер релизов не останавливался.

Выполняйте сборку быстро и тестируйте немедленно

Для поддержания высокой частоты релизов необходимо оптимизировать время сборки и тестирования. Инструменты сборки в CI/CD должны по мере необходимости применять слои кэширования, чтобы избежать дорогостоящих вычислений на основе статических ресурсов. Тесты должны быть оптимизированы так, чтобы не выполнять лишних обращений к сторонним службам.

Заключение

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

В решение Bitbucket от Atlassian встроены возможности CI/CD, позволяющие применять магистральную разработку. Попробуйте прямо сейчас.