部署相关问题 - 如何在部署期间处理失败的票证？

Question

（网络项目） 您好，我在开发期间使用用户故事/票证。我们也在使用sprint（scrum）。因此，一张票中描述了一个功能。所以在冲刺结束时我们会进行审核。审查后，我们有一些门票完成，一些失败。我很好奇我怎么才能只部署完成的门票/功能。

我正在考虑使用GIT为每张票创建一个分支。然后将完成的票证/分支合并到一个父分支。

还有什么想法？

Answer 1

我认为您选择使用的任何流程都需要一定的灵活性。

如果您为每个故障单使用主题分支，则可以选择在该冲刺结束时将任何明显不完整的分支合并回主分支。不幸的是，这会阻碍频繁的合并，并且你更有可能发生重大的合并冲突，因为每个人都试图在冲刺结束时合并变更，而不是在他们完成时，这会让其他人有机会将这些变化重新加入他们的历史。您还需要确保测试所有这些功能的最终合并，即使每个功能看起来都是完全独立的。

如果您经常合并，那么您不能轻易选择那些在事后通过审核的更改。但是，您可以采用来自持续部署的模式并构建新功能，并能够在您的版本中启用和禁用它们。代码更改可能位于主分支中，但您不必在考虑准备之前公开新功能。显然，这有一些开销，只对某些类型的更改有意义。

最后，您可能会尝试避免在sprint结束时执行所有审核工作。如果你可以让至少一对开发人员在将它合并到你的主分支之前检查一个功能并进行适当的测试，那么你应该能够保持主分支的质量，而不会增加太多的瓶颈。

希望你能找到适合你的东西。

Answer 2

  

我正在考虑使用GIT为每张票创建一个分支。然后将完成的票证/分支合并到一个父分支。   更多的想法？

这种方法虽然干净，但我们是否需要维护和合并。如果所有门票在他们自己的分支上工作正常并且在合并到主干时不会怎么办？

我的建议： 1.如果为每张票创建单独的分支，请进行QA以进行集成测试。 2.如果为每张票创建单独的分支，请确保Sprint用户故事足够独立，以便在合并后不会失败。

1. 你能用svn吗？使用svn，每次检入都会创建源代码的标记。 svn revert将还原与特定故障单相关的特定签入的更改。我不确定这是否可以在GIT中使用。

2. 尝试在Sprint和版本之间保持延迟。例如。你现在正在进行的冲刺，可以在2周后部署，这样你就有足够的时间进行合并，恢复或计划。