Магистральная разработка — одна из стратегий работы с ветками. Ее часто выбирают команды, которые используют непрерывную интеграцию и непрерывную доставку или развертывание (CI/CD).
При магистральной разработке программисты делают коммиты изменений прямо в основную ветку (мастер), а не создают отдельные функциональные ветки или ветки с исправлениями ошибок, которые объединяются с мастером позже.
При коммите изменений в основную ветку запускается CI/CD-пайплайн. Если в пайплайне обнаруживаются ошибки, все сотрудники подключаются к работе, чтобы как можно скорее их устранить. Задача — поддерживать мастер в состоянии готовности к развертыванию, часто выпуская обновления.
Если вы знакомы с принципами CI/CD, то, вероятно, уже поняли, что магистральная разработка отлично подходит для непрерывной интеграции и развертывания. Если все разработчики регулярно делают коммиты изменений, вы можете полностью контролировать ход работы и быстро получать обратную связь по новым сборкам.
Поскольку основную ветку необходимо постоянно поддерживать в рабочем состоянии и готовой к релизу, разработчики дополнительно тестируют свои изменения по ходу работы. Мониторинг метрик покрытия тестами поможет отслеживать этот показатель и гарантировать, что сборка кода сначала выполняется локально (и по возможности с базовым набором автоматических тестов) и лишь потом делается коммит изменений. Это позволяет уменьшить количество ошибок в мастере.
Некоторые сторонники магистральной разработки утверждают, что это единственный способ обеспечить непрерывную интеграцию, а использование функциональных веток лишь снижает эффективность CI/CD. Однако и у магистральной разработки есть свои минусы.
Она отлично подходит для непрерывного развертывания, которое предполагает автоматический релиз изменений кода, прошедших все этапы пайплайна. При этом лучше всего модель работает в SaaS-продуктах, где непрерывные обновления — норма.
Если же вы разрабатываете приложение для установки на локальном компьютере или мобильном устройстве, то, возможно, предпочтете выпускать обновления пакетами, а не создавать новую версию для каждого обновления, прошедшего пайплайн.
В этом случае, используя ветки, проще контролировать функции, вошедшие в определенный релиз, и поддерживать несколько версий продуктов.
Проблемой при магистральной разработке может стать развертывание больших и сложных функций. При регулярном коммите изменений в мастер с их развертыванием прямо в продакшн необходим способ управления функциями, которые еще не должны быть доступны пользователям.
Контролировать доступность функций можно с помощью флагов, но управлять ими бывает трудозатратно. Другой вариант — выбрать стратегию, использующую функциональные ветки. Тогда разрабатываемые функции окажутся отделены от мастера до тех пор, пока не будут готовы к релизу.
Если команда только начинает знакомиться с CI/CD, обеспечить коммит изменений прямо в мастер и одновременное поддерживать основную ветку в состоянии готовности к релизу может быть непросто: сначала нужно разработать надежный набор тестов. Если в целом стратегия магистральной разработки вам подходит, можно поставить себе целью перейти к ней, когда вы хорошо освоитесь в CI/CD.
Магистральная разработка — хороший вариант для непрерывной интеграции и развертывания, который лучше всего использовать, если у вас есть набор надежных автоматических тестов и вам не нужно поддерживать несколько версий ПО или объединять несколько обновлений в один релиз. Но помните, что это не единственный способ: в зависимости от обстоятельств, другие стратегии работы с ветками могут оказаться удобнее.