1

我正在为我和一个朋友设置Team Foundation Service 。我们将使用它来创建一些爱好项目。

我已经用一个团队项目设置了它，源代码控制目前的结构是这样的

$\Projects\CommonLib

$\项目\项目1

$\项目\项目2

Project1 是一个游戏，Project2 是一个 win8 应用程序，commonlib 是我们通用的、可重用的代码，Projec1 和 Project2 都将引用它们。每个项目将由一个包含多个项目的解决方案组成。

CommonLib 需要分发到这两个项目中。我最初的想法是将 CommonLib 二进制文件检入源代码控制文件夹并将其分支到其他两个项目，使用某种自定义 Team Build 流程进行部署。

不过有一个问题。像这样工作是相当乏味的，尤其是现在处于开发的早期阶段。我们希望能够快速将代码添加到 CommonLib，虽然当代码库已经成熟并且不会经常修改时，上述过程很好，但每次添加内容时执行所有这些步骤将是一件很麻烦的事情那里（构建->部署->合并）。

在规模的另一端，我们可以为例如 Project1 创建一个开发解决方案，其中还包含 CommonLib 项目。但是，这意味着如果我们错误地导致破坏性更改，我们可能会导致 Project2 出现问题。这可以通过上面描述的分支+合并策略更好地管理

所以我的问题是，我是否遗漏了任何可能使我们能够保留控制权同时仍能够将开发过程的复杂性保持在最低限度的选项？我确定这是一个常见问题。

4

2 回答 2

1

如果您不将二进制文件合并到产品空间中会有所帮助吗？

$\Projects\CommonLib\1.0\Source
$\Projects\CommonLib\1.0\Bin
$\Projects\CommonLib\Dev\Source
$\Projects\CommonLib\Dev\Bin

$\Projects\Project1

$\Projects\Project2

为 common 设置一个构建，让它将二进制文件检查到 Bin 文件夹中，然后让 Project1 和 Project2 共同引用它们。如您所见，我还在 Common 中添加了 Dev 的 1.0 分支，这样当 Project1 或 Project2 gewt 准备发布时，它们可以将 common dev 分支到版本化文件夹中，并将自己与其他项目更改为 common 隔离开来。

于 2012-08-10T00:17:41.530 回答
0

即使每个开发人员只对其中一个项目感兴趣，是否有任何理由不能在同一个构建解决方案中拥有两个项目？

由于两个项目都在一个解决方案中，而公共项目在同一个解决方案中，那么无论何时你们中的任何一个对公共模块进行更改，您都会立即知道是否在任何一个依赖项目中破坏了某些东西，因为一切都是构建在一起的。然后，您可以更新因更改公共模块而损坏的依赖代码，或与项目所有者协调以更新该代码。随着项目的成熟，您应该期望看到对公共模块的更改更少。

在一切构建干净并且单元测试通过之前，不要检查您的重大更改。如果您对公共模块进行重大更改，则您有责任修复所有相关代码。这建立了性格，并在不破坏已发布的界面或语义的情况下对核心更改的技能产生了新的认识。;>

显然，这种“包罗万象”的方法不适用于大型开发团队和大量项目。但是，当您与更大的团队合作时，您应该切换到自动构建/共享构建服务器工作流程，在该工作流程中，依赖项目决定它们所依赖的中间体构建，并可以决定何时“汇总”到他们更新的模块版本依赖 - 独立于依赖模块的发布周期。对于两个开发人员和两个具有公共代码的项目，您不需要这种级别的依赖关系管理。

于 2012-08-10T00:38:45.453 回答