奇怪的公司发布周期：进行分布式源代码控制吗？
抱歉，这篇文章很长，但我认为值得。 我刚从一家小型.NET商店开始，其运作方式与我工作过的其他地方有很大不同。与我以前任职的职位不同，此处编写的软件针对多个客户，并且并非每个客户都同时获得最新版本的软件。因此，没有“当前生产版本”。当客户确实获得更新时，他们还将获得自上次更新以来可能已添加到软件中的所有功能，而这可能是很久以前的事了。该软件是高度可配置的，并且可以打开和关闭功能：所谓的“功能切换”。此处的发布周期非常紧张，实际上它们没有按计划进行：功能完成后，软件便部署到了相关客户。 该团队仅在去年从Visual Source Safe迁移到Team Foundation Server。问题是他们仍然像使用VSS一样继续使用TFS，并在单个代码分支上强制执行Checkout锁定。每当将错误修复发布到现场时（甚至对于单个客户），他们都只需构建TFS中的内容，测试该错误是否已修复并部署给客户！（我自己来自制药和医疗设备软件背景，这真是难以置信！）。结果是半熟的开发人员代码甚至未经测试就投入生产。Bug总是会渗入发行版中，但是如果刚获得构建的客户通常不使用该bug所在的功能，他们将不会看到这些bug。主管知道这是一个问题，因为该公司正在逐渐发展壮大突然之间有一些大客户加入，而一些小客户也加入了。 有人要求我查看源代码控制选项，以消除错误的代码或未完成的代码的部署，但又不牺牲团队发行版的某种异步特性。在我的职业生涯中，我曾使用过VSS，TFS，SVN和Bazaar，但是TFS是我大部分经验的去处。 以前与我合作的大多数团队都使用Dev-Test-Prod的两个或三个分支解决方案，其中一个月的开发人员直接在Dev中工作，然后将更改合并到Test然后是Prod，或者在“完成时”升级，而不是在一个固定的周期。使用定速巡航或团队构建的自动化构建。在我之前的工作中，Bazaar被使用在SVN之上：开发人员在自己的小型功能分支中工作，然后将其更改推送到SVN（与TeamCity绑定）。很好，因为很容易隔离更改并与其他人的分支机构共享。 在这两种模型中，都有一个中央的dev和prod（有时是测试）分支，通过该分支推送了代码（标签被用来标记生产该版本的prod中的构建...这些都被制成了分支以修复错误。发布并合并回开发人员）。但是，这确实不适合此处的工作方式：没有命令何时发布各种功能，何时完成将它们推入。 有了这个要求，我看到的“持续集成”方法就失效了。为了获得与持续集成的新功能，必须通过dev-test-prod来推送它，这将捕获开发中所有未完成的工作。 我认为，要解决此问题，我们应该使用没有开发测试prod分支的大量功能分支模型，而是将源作为一系列功能分支存在，当开发工作完成时，这些功能分支将被锁定，测试，固定，锁定，经过测试然后发布。其他功能分支可以在需要/想要时从其他分支获取更改，因此最终所有更改都会被其他人吸收。这完全符合我上一份工作所经历的纯粹的Bazaar模型。 听起来如此灵活，但似乎没有某个开发主干或prod分支似乎很奇怪，我担心分支无法进行重新集成，或者后期的微小更改永远不会被其他分支和开发人员所抱怨。合并灾难... 人们对此有何想法？ 第二个最后一个问题：我对分布式源代码控制的确切定义有些困惑：有些人似乎暗示它只是没有像TFS或SVN这样的中央存储库，有人说这是关于断开连接的（SVN断开了90％并且TFS具有功能完善的离线模式），其他人则说这与功能分支和分支之间没有父子关系的合并的简便性有关（TFS也具有无基础的合并！）。也许这是第二个问题！