合并团队项目

发布于 2024-12-05 11:22:11 字数 466 浏览 8 评论 0原文

在我们当前的项目中,同一团队项目集合中有四个不同的 TFS2010 团队项目。原因是项目的不同部分想要使用不同的团队项目模板(CMMI 与敏捷)。

现在所有项目都使用相同的模板。因此,我们现在得出的结论是,最好将这些项目合并为一个团队项目。这就提出了几个问题:

  1. 使用现有项目之一作为其他三个项目的目标项目是否可能/可行?
  2. 我们如何将现有的工作项目转移到新项目中,同时维护我们的区域树?我们希望为每个现有团队项目创建一个根区域,并将所有工作项/区域移动到该根节点下。
  3. 今天,我们有从一个团队项目到另一个团队项目的工作项链接 - 合并时如何保留这些链接?
  4. 移动源代码时的最佳实践是什么?一种明确的方法是简单地将其复制到新位置,并锁定并保留旧的团队项目,以防我们需要访问旧版本的代码。但是为此使用分支是否可行,例如将所有现有代码分支到新的团队项目?这种方法可能会导致什么样的问题?

感谢您的帮助!

In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).

All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:

  1. Is it possible / feasible to use one of the existing projects as the target project for the other three?
  2. How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
  3. Today we have work item links from one team projects into another - how do we keep these links when merging?
  4. What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?

Thanks for your help!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦里梦着梦中梦 2024-12-12 11:22:11

不幸的是,TFS 2010 不允许您合并团队项目。

构建团队项目和团队项目集合是开始使用 TFS 之前要做的最重要的战略决策之一。不幸的是,我们帮助的许多客户在开始使用 TFS 之前并没有进行必要的前期规划,也不了解 TFS 中关于合并、移动、拆分等团队项目的一些限制: (

当我们进行咨询业务时,客户想要整合他们的团队项目,我们最终不得不做大量的手动工作来迁移工件。我们已经构建了一些工具来帮助我们完成工作项目的这个过程,但在大多数情况下很多迁移实用程序最终也需要为每个客户进行定制,因为他们通常对于如何迁移有不同的业务规则,

最终,“迁移”并不会带来所有的迁移 。信息,你最终会遇到一些其他问题,例如日期/时间戳与原来的不同(我听说它被称为迁移的时间压缩问题。)

对于每个原始问题的一些额外想法:

  1. 当然,理论上你可以使用其中之一以现有团队项目作为其他三个迁移的目标。只要您喜欢团队项目名称并且不想 重命名团队项目。 :)
  2. 我们在这里构建了自定义工作项迁移实用程序来帮助我们的咨询客户。您可能需要这样做。
  3. 使用自定义工作项迁移实用程序也可以实现这一点。您只需跟踪旧工作项 ID 和新工作项 ID 之间的映射,然后在目标团队项目中创建所有新工作项后添加链接。
  4. 这最终取决于你。我会做一个 对源代码从旧团队项目到新团队项目的“移动”版本控制操作。这维持了一切。但是,我不会删除任何旧的团队项目,因为这也会导致版本控制历史记录被破坏。

这不是最适合您的故事,但希望它能帮助您制定一些计划!

Unfortunately, TFS 2010 doesn't allow you to merge team projects.

Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(

When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.

Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)

Some additional thoughts for each of your original questions:

  1. Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
  2. This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
  3. This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
  4. That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.

It's not the best story for you but hopefully it will help your planning out some!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文