Слияние и ветвление общего кода между проектами в TFS

Question

В настоящее время я отвечаю за перенос наших приложений asp.net из исходного кода в TFS. У нас есть три или четыре очень похожих приложения (скажем, электронная коммерция), которые в настоящее время совместно используют основную библиотеку (сервисы, бизнес-логика, объекты, доступ к данным и т. Д.).

Приложения похожи, но не идентичны, поэтому одно приложение может получить набор функций, другие не получат и т. Д.

Я хочу прекратить совместное использование кода и вместо этого настроить ветви (если это подходит), поэтому, если я что-то изменю в основной библиотеке Приложения A, мне нужно будет объединить изменения с другими ветками, а не получать их автоматически. Это позволяет избежать неожиданностей, когда вы обновляете из своей ствола, и вдруг ядро ​​изменилось для другого проекта, и этот проект каким-то образом ломается.

Любые предложения о том, как мне настроить это в TFS? Должен ли я иметь «основное» ядро, которое не используется напрямую в каком-либо проекте, являющемся родителем всех других ядер, чтобы я мог перенести изменения этого ядра из одного ядра, а затем распределить его по другим ядрам? Имеет ли это смысл и будет ли легко настроить TFS?

Answer 1

В ответ на ваш комментарий я предлагаю вам прочитать Feature branches на сайте CodePlex .

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

Мой командный проект

      Development -> Isolated development branch container  
        Feature A -> Feature branch  
           Source  
        Feature B -> Feature branch  
          Source  
        Feature C -> Feature branch  
          Source  
        Main      -> Main Integration branch
          Source

Мы также переходим от SS к TFS в ближайшем будущем.

Как я понимаю, мы будем держать наш SS репозиторий в сети и начнем все сначала с TFS. Наш framework , вероятно, получит свой собственный проект в TFS. Специфичные общие единицы проекта должны время от времени объединяться.

---

Способ структурирования вашего хранилища зависит от вашей конкретной ситуации. У каждого сценария ветвления есть свои преимущества и недостатки.

• Сколько проектов
• Сколько разработчиков
• Выделены ли разработчики
• Нужны ли вам одновременные исправления
• Вам нужны сервисные пакеты

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

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

Answer 2

Я предполагаю, что вы уже исследовали, действительно ли вам нужно делать «копии» отдельных командных проектов. Помните, что концепция TFS «командного проекта» - это ОЧЕНЬ БОЛЬШОЙ контейнер высокого уровня. Это не то же самое, что большинство IT-магазинов считают «Проектом». Думайте о «Microsoft Vista» или «Office 2007» как о проекте, а не о «новом выпуске системы дебиторской задолженности компании XYZ» как о проекте в смысле Team Project.

У меня есть клиент, который выбрал один командный проект для TFS. В этом нет ничего плохого - и это действительно лучший сценарий во многих обстоятельствах.

Если вам действительно нужна очень сильная изоляция между вашими копиями приложения (возможно, они являются отдельными клиентами и вам нужно очень сильное разделение безопасности) и должны иметь отдельные командные проекты.

Это сказало - вы все еще - как вы заявили, необходимо делить код между экземплярами вашего приложения. Первое, что я бы настоятельно рекомендовал, это уйти от обмена «Вырезать и вставить». Я действительно попытался бы выделить общий код в отдельное решение и сгенерировать двоичные файлы для этого (возможно, вы уже сделали это!)

Это описано в Codeplex TFS: http://tfsguide.codeplex.com/

Другой подход, который я применил для нескольких клиентов, - это создать командный проект, содержащий общий код. «Build» создает двоичные файлы для общего кода, а «Deploy» просто копирует их в «известное местоположение» (т. Е. Общий ресурс UNC на компьютере сборки)

Для приложений, которые являются «потребителями» «Framework», мы просто использовали группу «AdditionalReferencesPath» для включения местоположения этого известного местоположения.

Более того - этот инструмент: http://tfsdepreplicator.codeplex.com/ может быть полезен. Это позволит вам автоматически запускать сборки для ваших «потребительских» проектов при создании решения «Framework».

Answer 3

Я пытался определить ту же информацию, это руководство по codeplex идеально

http://vsarbranchingguide.codeplex.com/releases

Включает терминологию и различные подходы к ветвлению, а также шпаргалки.

Answer 4

Мой краткий ответ заключается в том, что вы должны настроить только один «проект TFS» и просто упорядочить свои различные проекты, т.е. ваши отдельные приложения и каждую общую библиотеку, в виде отдельных папок в этом одном проекте TFS. Альтернативой является включение определенных (двоичных) сборок общих библиотек в каждое отдельное приложение - если вы сделаете это, вы можете организовать каждое приложение в свой собственный проект TFS, тем самым вы не сможете объединить изменения или разветвить эти проекты без использования TFS. командная строка (и некоторые неочевидные команды для загрузки).