Tfs 如何处理Team Foundation Server源代码管理结构中的共享项目

Tfs 如何处理Team Foundation Server源代码管理结构中的共享项目,tfs,shared-libraries,projects-and-solutions,Tfs,Shared Libraries,Projects And Solutions,读了之后,我想到了几个问题,我想知道是否有人可以对此发表评论 我有几个组件组成了我正在进行的一个项目。我有一个smartclient、一个webservice、一个smartclient使用的webservice的代理、一个守护进程和一个在smartclient和webservice中都使用的公共实用程序库。 每个组件都与同一个工作项目相关 我构建了我的源代码树,这样每个组件都是独立的——换句话说,每个组件(smartclient、webservice、守护程序、代理、公共实用程序)都有自己的主

读了之后,我想到了几个问题,我想知道是否有人可以对此发表评论

我有几个组件组成了我正在进行的一个项目。我有一个smartclient、一个webservice、一个smartclient使用的webservice的代理、一个守护进程和一个在smartclient和webservice中都使用的公共实用程序库。 每个组件都与同一个工作项目相关

我构建了我的源代码树,这样每个组件都是独立的——换句话说,每个组件(smartclient、webservice、守护程序、代理、公共实用程序)都有自己的主干和自己的解决方案文件,因为我希望能够独立发布每个组件。对于其他组件使用的组件,例如使用代理和公共实用程序的smartclient,我创建了与任何其他第三方库一样处理的版本(引用的是二进制文件,而不是项目)。有人能确认这是一种最佳实践吗?如果没有,应该如何进行


我一直在使用tfs build构建我的组件的发行版,我想知道除了所有tfs构建所在的build output目录之外,我应该把发行版放在哪里。我是否应该将它们(例如,smartclient使用的代理发布程序集)与任何其他第三方库一起检查到TFS中,然后在使用它们的地方将发布程序集分支(例如,将代理发布DLL分支到smartclient库目录)因此,您基本上是指通常所说的“依赖项复制”。 利用团队构建并复制您的依赖关系。有一个名为“依赖项复制器”的工具,它可以让您将构建链接在一起

例如,您的utilities类可能变化不大。但当它发生时,您需要确保: A) 它构建在服务器上 B) 所有依赖的项目也会生成


Dependency replicator允许您指定(XML)程序集如何相互依赖,以及更新依赖项时要运行的“生成”。

我们所做的是在TFS服务器上创建一个公共\common共享,其中包含与每个主要共享项目对应的子文件夹。例如:

\\common \sharedproject1 \v1.0.0 ... \vN.0.0 ... \sharedprojectN \\普通的 \共享项目1 \v1.0.0 ... \vN.0.0 ... \共享项目 我们的每个非共享项目都参考了\通用的\\共享项目中的特定共享组件

我们首先在需要时运行共享项目的自动构建。
然后将构建质量更改为特定值(例如“准备好供参考”)表示构建的输出需要自动复制到这些共享版本之一

然后,我们可以使用这些共享项目的输出为项目运行自动构建。
我们使用其他构建质量状态(如“准备进行系统集成”)来表示主应用程序的构建已准备好部署到特定环境(如测试)。
这会触发将项目输出打包到公共\release共享上的特定发布文件夹中。


最后,我们使用自动部署工具将给定版本安装到给定目标环境中的相应服务器上。

好吧,对于公共工具库,我有1.0、1.1和1.2版本,它们都是有效的,可以在不同的组件中使用。Smartclient依赖于1.0,而Webservice依赖于1.1。每个组件都有一个主干,对吗?在阅读了一些关于dependency replicator的文章后,您建议我看到这可能是我问题的一个解决方案。看见我想这有点像Maven for Java?谢谢。对不起,乔,我不太清楚马文。如果您有版本的发行版,则应始终使用主干/分支设计。每个分支都可以单独构建(即在TFS中有自己的构建定义),这反过来可能会触发DepReplicator的另一个构建。嗯