软件随想录(local.joelonsoftware.com/wiki)-2006年11月29日 在大型项目使用版本管理工具

2006年11月29日 在大型项目使用版本管理工具 - Using source control tools on huge projects

 

 

 

在大型项目使用版本管理工具

From The Joel on Software Translation Project

Jump to: navigation, search

在大型项目使用版本管理工具

在微软公司搞砸的所有事里，视窗开发团队使用版本管理的方式是得以幸免的项目之一。

一位年轻的视窗开发工程师写道：

「...在重启Longhorn项目之前，他们大约有七个分支（译注：branches，是版本管理工具常会提供的功能之一，可以将目前管理的项目发展出多个支线，每个支线可各自发展，却又保持有所关连。），然后大约每二或三周，将这些分支整合回主要分支上。现在，想像有数千个开发者将他们的程序代码直接提交（译注：check in，将开发者修改的部分程序代码上传到版本管理服务器）到这七个分支上，会导致以下两个状况：

「1.你频繁的提交程序代码，这很容易导致现有版本无法编译，或者操作系统功能有问题；2.相反地，假若你没有常常提交程序代码（这明显是很糟糕的事），会让你无法良好地回溯追踪修改历史。

「这明显地不具有弹性。因此重启项目之后，我们决定每个团队应该要有他们自己的功能分支，每个「功能分区」（跨多个团队）会再汇整成一个支线，最后整合成最终的主要支干。（因此目前有上百个分支，分属于大约六个支线之下）各团队可自由地选择他们需要的分支，并且可自由地决定上传修改部分到支线的频率。回归整合（译注：reverse-integration, RI,意思是将修改的内容汇整回主要支干）需要通过多种品质鉴定，像是效能测试。视评量关卡的多寡而定，至少会花掉一天的时间来进行这整个流程，再加上一两天的时间应付突发状况，所以进行一次RI需要相当的成本。然而，这些评量关卡都是为了确保主要支干上的产品的品质，如果没有这些关卡，这套操作系统大概永远无法推出。我认为这是那种「不会害死你」的交易(译：代价有点高但还是值得做)。

「有些团队的确以用不健康的方式来进行项目，像是数个月才RI一次，但这是这些个别团队的问题（或者说是他们的发布管理），而不是流程的错。一般来说，在品质方面越有纪律的团队，其RI的频率会更快更频繁。从你获得的系统元件稳定度/品质等级的变化资讯，可以轻易的推测出RI的速度等等，这是因为这些事情都是紧密的相连在一起。

在大型团队中使用版本管理机制时，最佳的方法是依各高阶功能分组，对个别的功能团队创造出分支跟子分支。假若工具能支持，甚至可以让每位开发人员有一个私有分支，这样一来，他们就可以随时提交到私有分支，直到自认程序代码稳定了才整合至团队分支。QA部门负责每次整合的合并点(junction point)。亦即当开发人员将私有分支的内容整合回团队的分支后，QA就态尽快查验，只有符合品质标准之后才能继续往上整合。

还是一头雾水吗？看一下Accurev这套软件的使用画面吧，上头有许多的「叶」分支，必须通过QA检验后功才能整合到更接近主线的分支。顺便一提，Accurev针对这种密集分支与整合的开发模式，做了一套很不错的版本管理系统。Windows开发团队使用他们自己的版本管理系统，不过谣传这其实是被买下源代码版权的旧版Perforce系统。Perforce在开发者间以昂贵稳固闻名，而且在处理超大型的程序代码库时效率很高。