Документацию Microsoft по стратегии ветвления стоит прочитать, главное - сделать все как можно проще.
Если вы используете многоступенчатые конвейеры , где этапы сборки (CI) и выпуска (CD) определены в коде yaml как один конвейер, тогда это побуждает вас создавать и развертывать код из одной ветки.
Если это действительно 2 разработчика и всего 2 функции, разрабатываемые / разрабатываемые одновременно, я бы сказал, что ветка разработки избыточна, и достаточно будет только основной и функциональной веток. Идея заключается в том, что функция A объединяется для управления и проходит весь путь через ваш конвейер до вашей реальной среды, прежде чем функция B будет объединена. Надеюсь, что в редких случаях, когда мастер ломается, тогда это «останавливает линию», и все работают над исправлением мастера до того, как будут объединены какие-либо дальнейшие функции.
Если вас беспокоит потенциальное нарушение мастера и единственный способ поднять уверенность Если этого не делать, это физическое развертывание в среде, вы можете исследовать архитектуры приложений, которые делают своевременное и экономичное развертывание сред на основе функциональной ветви (например, контейнерная ( AKS ) или бессерверная (Azure Функции )) и / или введение набора интеграционных тестов, который запускается во время сборки.
Большинство конвейеров pu sh одни и те же построенные артефакты из одной среды в другую минимизировать риск, особенно это практикуется с приложениями. net (пакет DLL и т. д. c). Проблема в сценарии, который вы описываете, заключается в том, что если вы выбрали фиксацию для функции A, а затем построили ее, вы собираетесь продвигать новую непроверенную версию приложения в производство. Вы не знаете, ошиблись ли вы с выбором вишни или, что еще хуже, некоторые вещи в функции B позволили функции A работать. Самым простым решением является более частое продвижение небольших изменений по всему конвейеру до производства (непрерывная поставка).
Удачи в проекте!