TFS - Непрерывная интеграция с разветвлением

Question

Вот мой сценарий (TFS Интернет - username.visualstudio.com/repo):

Я следующую структуру папок

--$ 
    --TimeManagement (.sln file at this level) 
    --WebApp (Main branch) (.csproj at this level) 
    --WebApp-Dev (Dev Branch) (.csproj at this level) 
    --WebApp-QA (QA Branch) (.csproj at this level) 
    --TestTimeManagement (Test Project) 

С этим я создаю сборка с настройками по умолчанию и мой вариант выпуска делают успешную сборку на лазурный веб-сайт. Это работает отлично, пока я не приду со следующими сценариями:

• мне нужно же/только тестовый проект, настроенный для основной & Dev филиала
• Мне нужно, чтобы изменить отрасль конкретной сборки, так что вместо .sln файла, я хочу сборка должна учитывать .csproj филиала.
• я могу внести изменения в закладке запуска каждой сборки в - непрерывную сборку - добавить фильтр с отраслевыми определенными папками
• В этом случае, мое DEV изменения ветви будет в основном выполнять связанные сборки и выполнение теста &, когда я, наконец, объединить свои изменения до основной ветвь, связанная с ней конструкция будет выполнена с тем же тестовым случаем.
• Я попытался поиграть с этим, однако сборка была перепутана с .csproj для решения. Он не может найти тест сборки - **\*test*.dll

Проще говоря, я ищу для установки TFS (онлайн, на данный момент), где будет несколько ветвей (Dev, основной, постановка, контроль качества) с единый тестовый проект и настраивать сборки, триггеры для определенных изменений в отрасли.

Сомнение: Можем ли мы создать филиал на .csproj уровне или только должны ветвление на .sln уровне?

Если я получу какой-либо справочный документ/видео, было бы здорово!

Answer 1

Сомнение: можем ли мы создать ветку на уровне .csproj или только разветвление на уровне .sln?

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

У меня есть настройка, где у нас есть несколько решений, и есть несколько проектов, которые либо используются одним решением, либо разделяются несколькими. Если они используются несколькими решениями, и вы вносите изменения в проект при работе над одним решением, есть вероятность, что вы можете нарушить другие решения. Поэтому для этого случая у меня есть решение master, которое имеет сборку CI, которая строит все проекты, чтобы убедиться, что ничего не сломано.

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

Существует различие между средами (Dev, QA, Prod) и ветвями. Отношения не должны быть 1: 1. Таким образом, у вас может быть 2 филиала (Dev, Main) и все еще есть много разных сред.