tfs2013 поделиться проектом по многим проектам

Question

У меня есть несколько (3) основных проектов, в которых я хочу поделиться многими решениями (12+).

Итак, скажем, у меня есть 12 веб-сайтов, и они используют какой-то общий основной код ядра (в данном случае я не говорю об общих js, css или представлениях - я говорю о бизнес-объектах, сущности и т. Д.).

Мне нужно определить, какой сайт имеет версию кода общего доступа в dev, test, prod и т. Д., Чтобы разработчик мог получить код сайта и получить правильную версию общего кода для разработки или патча веб-сайт.

И тогда сервер сборки MS должен знать, какую версию общего кода получить для развертывания.

Чтобы решить эту проблему, я вижу, что люди разделяют этот основной код - что кажется абсурдным делать 12+ раз. (Я ожидаю расшириться основного кода иногда для таких вещей, как исправлениями и длительных проектов.)

Я также видеть, что люди скопировать библиотеки DLL из основного кода и проверки тех, кто.

Я думаю, я будут перечислять зависимости для моих решений на основе имен таблиц TFS где-то, чтобы разработчики могли легко получить приложения, работающие с правильным кодом, и, учитывая метку tfs, сервер сборки может получить код для веб-сайта и правильную версию основного кода. Я тоже использую TFS & VS 2013, так что это так.

Итак, есть ли способ сделать это прямолинейным, поддерживающим/масштабируемым и интуитивно понятным? Спасибо - Peter

Answer 1

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

Кроме того, как отобразить зависимости для ваших решений на основе имен меток TFS? TFS не имеет этого встроенного параметра, кажется, единственный способ сохранить его в txt или некоторых других файлах и проверить исходный элемент управления. Каждый раз, когда разработчик открывает приложение для веб-сайта, необходимо сначала проверить его и получить ярлык от сервера в рабочее пространство и работать над ним.

Обычно целью совместного использования кода между проектами является сокращение обслуживания. Существует два основных пути совместного использования кода: исходный и двоичный. Разница между ними вы можете посмотреть в этом блоге: Code Sharing in Team Foundation Server

Обменный код между продуктами является основной причиной качественной эрозии и повышенных ошибок. Я бы рекомендовал вам отдельно построить и обмен двоичным кодом выход через NuGet который предпочтительнее.

Также смотрите ниже подобные вопросы:

• Sharing code between solutions in TFS
• TFS 2010 Branch Across Team Projects - Best Practices