在项目中使用SVN管理承包商

Question

在代码审查/管理变更等方面，使用SVN作为使用远程/外部开发人员管理项目开发的手段，您有什么建议？每个人都应该签入主干并为所有内容提供注释，还是人们使用补丁、分支或其他流程来管理这些内容？请提供任何建议，让一个小型的远程开发人员团队(5)将工作提交到SVN，以及一个单独的个人负责项目的开发谁审查代码更改，等等。

Answer 1

这个问题的答案将取决于：

• 你有多信任contractors?
• How ?你的团队想要投入多少精力来管理这件事？

以下是一些场景：

无信任

• Read only Read access
• 未完成对trunk
• Submissions的访问，您

中等信任

将您团队中的

• 读写里程碑branches
• Contractors submit to release branches.
• Somebody合并到发布分支

中

完全信任

负责合并其更改的trunk

• Contractors的
• 完全访问权限

至于最佳实践，我建议如下：

• 使用烧毁图表跟踪里程碑，或者您选择的系统
• 让每个人都使用注释提交(可以使用Subversion挂钩)
• Align代码提交到FogBugz、OnTime等管理系统中的特定项目/工单。
• 大型功能或里程碑应该有自己的分支。合并到主干1功能/里程碑已由团队中的某个人验证。

这里只有一些想法。你必须找到最适合你的团队成员和承包商的组合。

Answer 2

这取决于项目的具体情况。它是一个为完成一个项目而组建的团队，还是一个持续不断的版本努力。发布时间表等。

我们更接近后者。下面是我们的流程：

• 对于一个相当大的新版本/特性，我们创建一个单独的分支。
• 开发人员可以签入代码-我们推动每个签入都有注释。
• 为了与主干保持同步，分支所有者负责将主干合并到他的分支中
• 当功能/发布完成时，分支经过代码审查并合并回主干
• 分支被删除。如果分支上的工作必须继续，则必须重新创建分支-这是由于SVN

的限制

编辑

详细说明一下：

分支机构是正在进行的开发的游乐场。每个开发人员(或更大功能的开发人员领导)都对自己的分支负责，包括正确的签入过程(签入注释)以及与主干的同步。

另一方面，主干是一个稳定的地方-在任何时候，你都应该能够在主干上构建应用程序的工作版本。事实上，我们有一个CI流程，每次签入时都会自动执行。

为了实现这种稳定性，永远不会直接对主干进行更改(除了smth非常小并且非常紧急)。

修改主干的过程是内部开发人员的责任。一旦分支的所有者声明它已经准备好投入生产，内部开发人员就必须审查提交的代码(来自分支)，并将其合并回主干。

在合并回来之后，分支变得不可用，必须删除。