奇数公司发布周期: Go分布式源代码管理？

Question

很抱歉这么长的帖子，但我认为这是值得的。

我刚从一家.NET小店开始，它的经营方式与我工作过的其他地方有很大的不同。与我以前的任何职位不同，这里编写的软件是针对多个客户的，并不是每个客户都同时获得软件的最新版本。因此，没有“目前的生产版本”。当客户确实得到更新时，他们也会获得自上次更新以来添加到软件中的所有功能，这可能是很久以前的事了。该软件是高度可配置的，功能可以打开或关闭:所谓的“功能切换”。发布周期在这里非常紧凑，实际上它们并不在计划之内:当一个特性完成后，软件就会被部署到相关的客户。

该团队仅在去年才从转移到。问题是，他们仍然像使用VSS一样使用TFS，并在单个代码分支上强制执行Checkout锁。每当一个bug修复被放到字段中(即使是单个客户)，他们只需构建TFS中的任何内容，测试bug已经修复并部署到客户！(我本人来自制药和医疗器械软件背景，这真是难以置信！)其结果是，半生不熟的开发代码会在没有经过测试的情况下投入生产。bug总是滑向发布版构建，但通常情况下，刚得到版本的客户如果不使用bug所包含的特性，就不会看到这些bug。这位董事知道这是一个问题，因为随着一些大客户和更小客户的加入，公司正开始迅速增长。

我被要求考虑源代码控制选项，以消除部署but或未完成的代码，但不要牺牲团队发布的某种异步性质。在我的职业生涯中，我使用过VSS、TFS、SVN和Bazaar，但TFS是我的大部分经验所在。

在此之前，我曾与大多数团队一起使用developers的两到三个分支解决方案，开发人员在其中一个月内直接在Dev中工作，然后将更改合并到Test然后Prod，或者在“完成时”而不是在一个固定的周期上进行升级。使用自动构建，使用Cruise Control或Team Build。在我以前的工作中，Bazaar被使用在SVN之上: devs在自己的小特性分支中工作，然后将它们的更改推到SVN(它绑定到TeamCity中)。这很好，因为很容易隔离变更并与其他人的分支共享它们。

对于这两个模型，都有一个中央dev和prod (有时还包括测试)分支，通过它们推送代码(标签用于标记prod中的构建，其中版本是made...and，这些分支被制成分支，用于对版本进行错误修复，并合并到dev)。然而，这并不适合这里的工作方式:当各种特性发布时，当它们完成时，它们就会被推送。

有了这个需求，我认为“持续集成”方法就会崩溃。要想通过持续集成获得一个新特性，就必须通过dev-test-prod来推动它，这将捕获dev中任何未完成的工作。

我认为为了克服这一问题，我们应该采用一个没有开发测试分支的重特性分支模型，而应该将源代码作为一系列特性分支存在，当开发工作完成时，这些分支被锁定、测试、修复、锁定、测试，然后发布。其他特性分支可以在需要/需要时从其他分支获取更改，因此所有更改最终都会被吸收到每个人的身上。这非常符合我在上一份工作中所经历的纯粹的集市模型。

虽然这听起来很灵活，但没有开发主干或prod分支似乎很奇怪，而且我担心分支分叉永远不会重新集成，或者对其他分支和开发人员抱怨合并灾难的小的后期更改。

人们对此有何看法？

第二个问题:对于分布式源代码管理的确切定义，我有些困惑:有些人似乎认为这是关于没有像TFS或SVN这样的中央存储库，有些人说这是关于断开(SVN为90%断开，TFS具有完美的功能离线模式)，而另一些人则认为它是关于特性分支和在没有父-子关系的分支之间合并的(TFS也有无根据的合并！)也许这是第二个问题！

Answer 1

什么定义了DVCS?

DVCS中的分布式意味着存储库的每个克隆都拥有提交、更新、分支、合并或搜索存储库中任何版本所需的所有信息，而无需接触服务器。在svn中唯一能做的离线操作就是编辑文件--几乎所有的svn命令都需要服务器访问，包括做一些简单的事情，比如打招呼svn log，所以它实际上更接近0%，而不是90%！

您可能在DVCS工作流中设置的任何权威的中央存储库都只是另一个克隆，您唯一需要与其交互的时间是当您删除其他人的更新或推送您自己的更改以便其他人能够看到它们时，几乎所有其他事情都可以脱机完成。

什么分支模型比较合适？

我一直处于你现在的处境。这样的系统可能是一种真正的痛苦，但你必须理解它们变成这样的实际原因，并意识到它们并不是不可挽回的。已经开发了许多工具来帮助管理这种复杂性。

首先，不管你做什么，不要向人们展示成功的git分支模型，它只会让他们感到困惑，并把他们关掉。相反，开发您自己的模型，以反映您现有的工作流，但解决您现有工作流的问题。

您可能需要考虑的一些资源包括git 子模，它将允许不同的客户版本指定客户配置、应用程序模块和库的不同组合。另一种选择是使用补丁管理系统应用特定于客户/产品的补丁队列。

这两种选择都将提供比当前工作流更大的灵活性、透明度和安全性，并且可能比只使用更复杂的分支策略更容易使用。我当然希望在你的情况下我能接触到这些工具。

有关这些选项的更多信息，请参见我对模块化系统中使用版本控制的策略、如何使用中的颠覆仓库？和多家公司使用的应用程序的源代码/版本控制的回答。

最终，这确实是你必须与团队其他成员一起开发的东西。如果你有远见，提出比你已经拥有的更好的东西，并能得到你的同事的购买，那么你将有一个更容易的时间。

最重要的是向你的同事们展示你的建议如何让他们的生活更轻松。一旦他们确信，你就有更好的机会让管理层放弃对TFS的投资，并开始使用更适合您的工作方法的模型。

Answer 2

第二个问题更简单更短，所以我将尝试从它开始--

DVCS是一种系统，没有一个“权威”的代码来源(除非使用“在协议上”)和p2p-数据交换是不可能的额外层(个人的，非规范的定义)。

关于这个主题的第一个问题

我担心，公司必须重建工作流程，重新考虑风格，才能得到“某种程度上的管理和可预测的代码”。我不能说TFS (除了个人的观点和感觉，它在版本控制部分/baseless合并中是脆弱的系统是邪恶的/)，但是对于您的情况下的任何VCS (“产品”是一组独立的“模块”，每个“客户”得到不同的“产品”-这个假设正确吗？)我更喜欢将模块的开发分成不同的分支，将Product为"Supermodule“(也是分支？)，其中每个模块都与模块分支的特定修订相关联，模块开发使用的是按任务划分的分支模式(并且模块-分支仅由合并组成)。

通过这种方式，您可以始终知道哪些“集合”(即模块集及其相应的修订版)构成了每个“产品”，可以进行CI (已完成和合并的任务-分支)、单元测试和构建。

Answer 3

广告的主要问题:我相信您正在谈论的正是git成功分支模型 (以及支持它的辅助工具git流 )的内容。拥有一个主分支，该分支始终处于可部署状态，并对特性分支执行所有工作。

您还可以使用git本身使用的过程，git是从相同的基本原则派生而来的。在git核心开发中，所有的工作都发生在特性分支上。特性分支被提交给integrator，它运行一个脚本来合并所有这些分支，以创建一个名为pu (建议更新)的分支。很多人拿着这个分支，用它来测试它。

与integrator不同，您可以让持续集成服务器在构建开始时进行此合并。这样，每当团队中的任何人将对中央存储库的更改推入特性分支时(可能使用一些命名约定来判断应该选择哪些分支)。

在git中，特性分支比进入next、master或maint的功能分支更重要，这取决于它针对哪个版本(maint用于修复当前版本，掌握当前准备版本，下一个用于后续版本)，但不会有那么多。

虽然这些特性都是在pu ( git维护者术语中的“烹饪”)中实现的，但是它们会被回绕，每次都会丢弃pu分支并重新创建，这使得查看变得更容易，但不适合基于其他工作。当特性分支合并到一个主线中时，它将被关闭以进行回绕，并在新提交时进行进一步的修复。

我个人认为git是最好的。一开始学习起来有点困难，因为它会更有机地发展，但最终它似乎是最灵活的。但是这三种分布式系统中的任何一种，git、mercurial和bazaar都能很好地为您服务(您甚至可以将它们混合在一起，例如，mercurial可以从git存储库中提取和推送，我相信市场也可以这样做)。

广告第二个问题:我被告知，“分布式”，一般意味着你可以移动物体，并保持他们的身份。这正是分布式版本控制所做的:克隆存储库，它包含相同的提交，并允许对它们执行相同的操作。分支的易用性和断开的操作是主要的用户级特性，它遵循移动提交的原则和允许它的有向图布局。