Как работать с общими проектами в структуре управления исходным кодом сервера Team Foundation

Question

После прочтения Структура управления исходным кодом сервера Team Foundation , за которой я следовал, несколько вопросов приходят к выводу, что мне интересно, может ли кто-нибудь прокомментировать.

У меня есть несколько компонентов, которые составляют проект, над которым я работаю. У меня есть smartclient, веб-сервис, прокси для веб-сервиса, который использует smartclient, демон и библиотека общих утилит, которая используется как в smartclient, так и в веб-сервисе. Каждый из компонентов связан с одним и тем же рабочим проектом.

Я структурировал дерево исходных текстов таким образом, чтобы каждый из компонентов был независимым - другими словами, каждый компонент (smartclient, webservice, daemon, proxy, общие утилиты) имеет свою собственную магистраль и собственный файл решения, так как я хочу, чтобы выпускать каждый компонент самостоятельно. Для компонентов, которые используются другими компонентами, например, в случае, когда smartclient использует прокси-сервер и общие утилиты, я создал выпуски, которые обрабатываются как любая другая сторонняя библиотека (двоичные файлы, на которые ссылаются вместо проектов). Может ли кто-нибудь подтвердить, что это в некоторой степени лучшая практика, и если нет, то как это сделать иначе?

Я собирал релизы своих компонентов, используя сборку tfs, и мне интересно, куда я должен поместить релизы, если где-нибудь, кроме выходного каталога сборки, где находятся все сборки tfs. Возможно, я должен проверить их (например, сборки релизов прокси, которые будут использоваться smartclient) в TFS вместе с любыми другими сторонними библиотеками, а затем разветвить сборки релизов там, где они будут использоваться (например, библиотеки dll выпуска прокси-серверов ветки в каталоге lib smartclient)

Answer 1

Мы создали общедоступный общий ресурс \ common на сервере TFS, содержащий подпапки, соответствующие каждому основному общему проекту. Например:

\\common  
    \sharedproject1
        \v1.0.0
        ...
        \vN.0.0
    ...
    \sharedprojectN

Каждый из наших проектов без общего доступа ссылается на определенные общие сборки in \ common \ sharedprojectN \ v Mmn

Сначала мы запускаем автоматические сборки общих проектов, когда это необходимо.
Затем изменение качества сборки на конкретное значение (например, «Готовность к справке») указывает на то, что выходные данные сборки необходимо автоматически скопировать в одну из этих общих версий.

Затем мы можем запускать автоматические сборки для проектов, используя выходные данные этих общих проектов.
Мы используем другие статусы качества сборки (например, «Готовность к системной интеграции»), чтобы указать, что сборка основного приложения готова к развертыванию в конкретной среде (например, тестирование).
Это инициирует упаковку выходных данных проекта в определенная папка релиза в нашей общедоступной папке \ release .

Наконец, мы используем инструменты автоматического развертывания для установки данного выпуска на соответствующие серверы в заданной целевой среде.

Answer 2

Итак, вы, по сути, имеете в виду то, что обычно называют «репликацией зависимостей». Используйте Team Build и копируйте свои зависимости. Существует инструмент под названием «Dependency Replicator», который позволит вам создавать цепочки вместе.

Так, например, ваш класс утилит может не сильно измениться. Но когда это произойдет, вам необходимо убедиться, что: А) Он строится на сервере Б) Все зависимые проекты строятся так же.

Репликатор зависимостей позволяет указать (в XML), как сборки зависят друг от друга и какую «сборку» запускать при обновлении зависимости.