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

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

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

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