0

一个 TFS 多个项目 许多 .cs 文件... 许多软件工程师 许多检查同时开发的所有项目。

有些项目提前结束,必须部署,但有些项目还没有完成。

我们做什么,我们注释属于未完成项目的代码部分是否有任何方法比 TFS 2008 上的手动方法更好

4

2 回答 2

3

在您最终遭遇火车事故之前,您需要查看您的分支策略......请参阅此处以获取良好的指南。每个不同的版本都应该有一个分支。在分支之间合并代码有少量额外的工作,但它会导致每个版本都有一个可重复测试的“主”分支。还要看看你是如何切割标签的,以及你的持续集成是如何设置的(如果你目前没有的话,那就煽动它)。

于 2012-06-11T08:22:39.950 回答
1

There's no secret out there, you have two main choices:

1) You have one branch per project that can be atomically released, then when you do a global release you merge only the branches of the projects that are ready to released to the global release branch. (it's a merge from latest)

2) All your projects are in only one branch (can be the case if you really do have a lot of project, too many to go 1 branch per project), then you must rely on traceability (whether using Work Item or a custom list of Changesets) to merge only the changesets of the ready to released projects to the global released branch. (it's a cherry pick merge of changesets)

Okay there's a third secret choice:

3) Use a blend of 1 & 2, if you have for instance 200 projects, you can certainly create something like 10 "groups of projects" to store all the projects that are related (technically or functionally) into one branch. Then you end up with 10 branch of 20 projects each with the constraint that all projects inside a branch must be "ready for release" to be merged in the global release branch.

1) is easy to implement, but won't be a good idea if you have a lots of projects (>20) 2) offers the best flexibility but you have to be pretty prepared and organized to set it up. 3) is still a mix of 1 & 2 both for pros & cons.

于 2012-06-11T08:55:28.253 回答