如何处理团队基础服务器源控制结构中的共享项目

时间:2009-01-22 10:20:27

标签: tfs shared-libraries projects-and-solutions

在阅读了Team Foundation Server Source Control Structure之后我想到了一些问题,我想知道是否有人可以评论。

我有一些组件组成了我正在处理的项目。我有一个smartclient,一个web服务,一个smartclient使用的web服务的代理,一个守护进程和一个在smartclient和webservice中使用的通用实用程序库。 每个组件都与同一个工作项目相关。

我构建了我的源代码树,以便每个组件都是独立的 - 换句话说,每个组件(smartclient,webservice,daemon,proxy,common utilities)都有自己的trunk和自己的解决方案文件,因为我希望能够独立发布每个组件。对于其他组件使用的组件,例如在使用代理和常用实用程序的smartclient的情况下,我创建的版本与任何其他第三方库(引用的二进制文件而不是项目)一样处理。任何人都可以确认这是一种最佳实践,如果不是,应该怎么做呢?

我一直在使用tfs构建构建我的组件的版本,并且我想知道除了在所有tfs构建所在的构建输出目录之外的任何地方我应该放置哪些版本。我是否应该将它们(例如智能客户端使用的代理发布程序集)与任何其他第三方库一起检查到TFS中,然后将发布程序集分支到它们将被使用的位置(例如,分支代理发布dll到smartclient lib目录) ?

2 个答案:

答案 0 :(得分:3)

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

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

共同 \ 共享项目N \ v Mmn 中的每个非共享项目引用特定共享程序集

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

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

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

答案 1 :(得分:2)

所以你基本上指的是通常所说的'依赖复制'。 使用Team Build并复制您的依赖项。有一个名为“Dependency Replicator”的工具可以让你将构建链接在一起。

例如,您的实用程序类可能没有太大变化。但是当它发生时,你需要确保: A)它建立在服务器上 B)所有依赖项目都会建立。

依赖关系复制器允许您指定(在XML中)程序集彼此之间的依赖关系,以及在依赖关系更新时运行的“构建”。