一个很好的工作流程，从连续交付开始？

Question

在不久的将来，我的团队将面临几个新的挑战，因为我们将开始开发一些将在云环境中运行的(微)服务。因此，我们希望建立一个连续的交付工作流(并且可能有一天继续进行连续部署)。

目前，我们正在开发一个基于Eclipse的应用程序以及一些web应用程序(Java )。在我们提供了发布的工件之后，客户负责操作。我们每年发布3-4次，并在需要时提供额外的维护版本。我们使用git与基于主干(全主程序)的工作流和额外的维护分支。开发人员每天至少提交一次，这将触发我们的CI服务器上的构建。主人可能会偶尔变得不稳定，并且包含许多不完整的(而不是隐藏的！)功能。

由于我们将负责服务的操作，我们的主要目标是始终准备好发布的主线，以便在考虑使用特性分支扩展git工作流时，快速响应broken.Thus。但是我们很快就放弃了这个想法，因为几个原因(例如，合并与功能/故事的冲突需要1-2周，没有令人满意的CI反馈等)1-2。因此，我们决定保留我们的全主工作流(没有维护分支)，并使用诸如特性切换、按抽象分支等模式( 3-4 )。然而，我们对这些模式并没有太多的经验，并且认为始终保持主线100%干净并随时发布是非常重要的。因此，我们决定增加一个开发分支，在需要时或至少在sprint结束时将其合并。这确保了主分支确实保持了发布准备，而开发分支不必这样做(当然应该是这样)。

在这个工作流建立之后，我们想更进一步，引入一些短活的特性分支。在我看来，特征分支的主要问题来自于它们相当长的生命周期。假设您有一个由几个子任务组成的用户故事。一项任务大约需要一天的工作时间。当任务完成后，更改将被推送到主线，这将触发构建服务器上的完整构建。这是我们所知道的CI，对吗？但是，我的提交仍然会导致不稳定的主线。当然，我可以在本地运行所有单元测试，但是构建服务器可能会运行额外的测试，或者检查我不想在本地运行的其他质量指标。因此，有一个专门的分支并为我的任务构建工作将是很好的。这使我能够在将更改推送到主线之前验证和检查更改。因此，我抓取一个子任务来工作，并自动获得一个特性分支并构建作业。当任务完成后，它被推送到主线，branch+build作业被清理干净。

例如，我知道这个工作流类似于'gitflow‘，但是主要的区别是上面提到的分支的生存期。

你对这个工作流有什么看法？您使用哪些工作流？

(1)“连续交付”，Jez Humble和David Farley，(2) martinfowler.com，FeatureBranch，(3) martinfowler.com，FeatureToggle，(4) martinfowler.com，BranchByAbstraction，

Answer 1

如果我正确地理解了你的问题，那么你在任何时候都想要一个“干净的主人”的唯一原因是，你可以“在有东西坏了的时候迅速做出反应”。我认为最好是在发布分支上进行修补，而不是将所有非热修复任务转移到非主分支。

基本上，您可以像往常一样在master上完成所有的开发工作，然后当sprint结束并执行一个发行版时，您可以从主服务器上“切断”一个分支，并将其称为"releases/20150411“。然后，如果您在生产中发现了一个bug，您就会发现哪个发布分支会受到它的影响，然后向那些发布分支应用一个补丁，然后将补丁版本重新部署/重新部署/等到有坏版本的用户。这实际上比“干净主”方法更灵活，因为您可以很容易地拥有多个发布分支(假设您有几个部署阶段，就像我们所做的那样)，从而最小化了意外地向“最远的”用户组添加新的bug /特性的风险，这是修复当前错误的副作用。