Close

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

Узнайте, почему такой метод управления версиями популярен среди команд DevOps.

Фотография: Кев Зеттлер
Кев Зеттлер

Специалист по комплексной веб-разработке


Магистральная разработка — это метод контроля версий, при котором разработчики объединяют небольшие частые обновления с центральной «магистралью», или главной веткой. Поскольку этот метод упрощает этапы слияния и интеграции, он помогает добиться CI/CD, ускорить поставку программного обеспечения и повысить производительность организации.

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

По мере развития систем контроля версий появились различные стили разработки, позволяющие программистам проще находить баги, писать код параллельно с коллегами и повышать частоту релизов. Сегодня большинство программистов используют для создания качественного программного обеспечения одну из двух моделей разработки: Git-flow или магистральную разработку.

Рабочий процесс Git-flow, который был популяризирован первым, представляет собой более строгую модель разработки, в которой одобрять изменения основного кода могут лишь определенные люди. Это позволяет обеспечить качество кода и свести количество багов к минимуму. Магистральная разработка — более открытая модель, поскольку доступ к основному коду имеют все разработчики. Это позволяет командам быстро выполнять итерации и внедрять CI/CD.

Что такое магистральная разработка?

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


Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. It’s a common practice among DevOps teams and part of the DevOps lifecycle since it streamlines merging and integration phases. In fact, trunk-based development is a required practice of CI/CD. Developers can create short-lived branches with a few small commits compared to other long-lived feature branching strategies. As codebase complexity and team size grow, trunk-based development helps keep production releases flowing.

Сравнение Git-flow и магистральной разработки

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


Gitflow is an alternative Git branching model that uses long-lived feature branches and multiple primary branches. Gitflow has more, longer-lived branches and larger commits than trunk-based development. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge as they have a higher risk of deviating from the trunk branch and introducing conflicting updates. 

См. решение

Разработка и эксплуатация программного обеспечения с помощью Open DevOps

Связанные материалы

Как перейти к непрерывной интеграции

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

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

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

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

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


Trunk-based development is a required practice for continuous integration. If build and test processes are automated but developers work on isolated, lengthy feature branches that are infrequently integrated into a shared branch, continuous integration is not living up to its potential.

Trunk-based development eases the friction of code integration. When developers finish new work, they must merge the new code into the main branch. Yet they should not merge changes to the truck until they have verified that they can build successfully. During this phase, conflicts may arise if modifications have been made since the new work began. In particular, these conflicts are increasingly complex as development teams grow and the code base scales. This happens when developers create separate branches that deviate from the source branch and other developers are simultaneously merging overlapping code. Luckily, the trunk-based development model reduces these conflicts.

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

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

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

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

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

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

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

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

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

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


Trunk-based development ensures teams release code quickly and consistently. The following is a list of exercises and practices that will help refine your team's cadence and develop an optimized release schedule.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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


Trunk-based development is currently the standard for high-performing engineering teams since it sets and maintains a software release cadence by using a simplified Git branching strategy. Plus, trunk-based development gives engineering teams more flexibility and control over how they deliver software to the end user.

Kev Zettler
Kev Zettler

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


Поделитесь этой статьей

Рекомендуемые статьи

Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.

Рисунок: DevOps

Сообщество DevOps

Рисунок: DevOps

Узнать больше в блоге

Рисунок: карта

Начните работу бесплатно

Подпишитесь на информационную рассылку по DevOps

Thank you for signing up

продолжение темы
Software testing for continuous delivery