如何处理团队基础服务器源代码控制结构中的共享项目 [英] How to handle shared projects in team foundation server source control structure

问题描述

在阅读了我遵循的 Team Foundation Server 源代码控制结构之后我想到了几个问题，我想知道是否有人可以评论.

我有几个组件组成了我正在处理的项目.我有一个智能客户端、一个 web 服务、一个智能客户端使用的 web 服务的代理、一个守护进程和一个在智能客户端和 web 服务中使用的通用实用程序库.每个组件都与同一个工作项目相关.

我已经构建了我的源代码树，以便每个组件都是独立的——换句话说，每个组件(智能客户端、网络服务、守护进程、代理、通用实用程序)都有自己的主干和自己的解决方案文件，因为我希望能够独立释放每个组件.对于其他组件使用的组件，例如在使用代理和通用实用程序的智能客户端的情况下，我创建了像任何其他 3rd 方库(引用的二进制文件而不是项目)一样处理的版本.任何人都可以确认这在某种程度上是最佳实践，否则应该如何做?

我一直在使用 tfs build 构建我的组件的版本，我想知道如果不是在所有 tf​​s 构建所在的构建输出目录中的任何地方，我应该把这些版本放在哪里.我是否应该将它们(例如智能客户端使用的代理发布程序集)与任何其他 3rd 方库一起检查到 TFS 中，然后将发布程序集分支到要使用的位置(例如分支代理发布 dll 到智能客户端库目录)?

解决方案

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

<预>\\常见的\共享项目1\v1.0.0...\vN.0.0...\共享项目N

我们的每个非共享项目引用特定的共享程序集\common\sharedprojectN\vMmn

我们首先在需要时运行共享项目的自动构建.
然后将构建质量更改为特定值(例如Ready For Reference")表示构建的输出需要自动复制到这些共享版本之一.

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

最后，我们使用自动化部署工具将给定版本安装到给定目标环境中的适当服务器上.

After having read Team Foundation Server Source Control Structure which I have followed a few questions come to mind that I am wondering if anyone can comment on.

I have a few components that make up a project I am working on. I have a smartclient, a webservice, a proxy for the webservice that the smartclient uses, a daemon and a common utilities library that is used in both the smartclient and the webservice. Each of the components are related to the same work project.

I have structured my source tree so that each of the components is independent - in other words each component (smartclient, webservice, daemon, proxy, common utilities) has its own trunk and its own solution file as I want to be able to release each component independently. For components that are used by other components, such as in the case of the smartclient using the proxy and the common utilities, I have created releases that are handled like any other 3rd party library (binaries referenced instead of projects). Can anyone confirm that this is somewhat a best-practice and if not how should this be done otherwise?

I have been building releases of my components using tfs build and am wondering where I should put the releases if anywhere other than in the build output directory where all the tfs builds reside. Should I perhaps check them (e.g. proxy release assemblies to be used by the smartclient) into TFS along with any other 3rd party libraries and then branch the release assemblies where they are to be used (e.g. branch proxy release dlls to the smartclient lib directory)?

解决方案

What we have done is creating a public \common share on the TFS server which contains subfolders corresponding to each major shared project. E.g.:

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

Each of our non-shared projects reference specific shared assemblies in \common\sharedprojectN\vM.m.n.

We first run automated builds of shared projects when needed.
Then changing the build quality to a specific value (e.g. "Ready For Reference") indicates that the output of the build needs to be automatically copied to one of these shared versions.

We can then run automated builds for projects using the output of these shared projects.
We use other build quality statuses (e.g. "Ready for System Integration") to indicate that a build of a main application is ready for deployment to a specific environment (e.g. test).
This triggers the packaging of a project output into a specific release folder on our public \release share.

Finally we use automated deployment tools to install a given release onto the appropriate servers in a given target environment.

这篇关于如何处理团队基础服务器源代码控制结构中的共享项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！