您的敏捷工作流程是什么样的，特别是发布频率和源代码管理？ [关闭]

Question

我的团队正在讨论管理用户发布的最有效方法。 这是我们目前为期2周的冲刺周期的工作流程：

1. 我们在干线上开发一切
2. 我们有一个夜间Team City构建，推送到我们的Nightly Build服务器
3. 我们的BAs / QAs评估每晚构建并决定何时推广到QA / UAT
4. 在sprint结束时，我们将主干上的任何内容推送到UAT。

我们所看到的最大问题与在干线上开发的所有东西有关。 由于不完整的故事会在行李箱中办理登机手续 ，因此我们的夜间搭建偶尔会出现问题。 这种情况也可能发生在冲刺结束时，例如，一个包含6个任务 （其中3个已完成 ）的故事已经被检入到主干。

我认为用户应该只评估完整故事或修复bug的工作量。 具有6个任务的故事在完成这6个任务之前不会完成。

一个建议的工作流程就是这个（但有一些问题）：

1. 我们在' sprint分支 '上发展。 sprint中完成的所有操作都会检入此分支。 当故事的所有任务完成后，分支将合并到主干，并生成每晚构建。
2. 在sprint结束时，我们合并到trunk。

问题在于，对于步骤1 ，当我们合并到主干时，我们也可能合并不完整的故事（ 步骤2也是如此 ）。

这让我们得到了这个建议的工作流程

1. 对于每个故事，我们创建一个故事/功能分支。
2. 当一个故事完成后，我们从主干合并（ 获取其他完整的故事和错误修复 ），然后合并到主干 。 Trunk现在包含一个新完成的故事 。
3. 然后我们生成一个夜间构建

这听起来像是可以解决与不完整故事相关的大多数问题。 但是，它引入了多个分支的复杂性和开销。

我们很想知道你做了什么，特别是如果你：

• 在后备箱上发展
• 在与sprint相关的分支上发展
• 开发功能/故事分支

如果你使用一个分支接近 ，那引入了什么开销，是否值得。

Answer 1

我们在trunk上开发，但是在迭代结束时我们从未有过不完整的Stories。 我们没有不适合一次迭代的故事。 更大的故事被分成更小的故事。