当我们必须共享相同的QA环境时，我们应该如何构建用于敏捷/Scrum开发的SVN环境？

Question

我的任务是为我们向敏捷的过渡提出一个svn结构，该结构必须扩展到多个团队(有多个开发人员)。在与我的同事交谈后，我提出了下面所示的示例结构。我从其他有合法顾虑的团队成员那里得到了一点回击。当我们都必须共享一个QA环境时，我希望找到在多个团队中拥有svn结构的最佳实践。

​

​

在我上面的例子中，你可以看到我使用了很多敏捷/Scrum术语。我这样做是为了帮助解释我为什么提出这个结构的决定。从本质上说，“主”主干将始终只有来自所有团队的故事，这些团队已经满足了“完成的定义”，其中包括QA。向我指出的主要问题是，我们必须共享环境(由于某些原因，我们不能虚拟化这些环境)，因此，每天发布QA测试将很困难，因为每个团队都会互相跨越。他们想要解决的另一个问题是，一些人不希望每个开发人员都有自己的分支，因为这将增加每个团队/个人必须进行的合并数量。

在这一点上，我不确定该怎么做，我们该如何回应。我希望这里的一些人/团队能告诉我们他们是如何构建他们的架构的，以及由于您的架构您遇到了什么问题。

Answer 1

我建议你看看Jez Humble和David Farley的“持续交付”。他们深入讨论了分支策略的许多细节，并特别谈到了SVN。

你在推动频繁的发布吗？如果是这样，那么最好的方法通常是让所有团队都提交到主干中。分支的唯一时间是在发布时，这样您就可以立即修复生产问题，而不必担心正在进行的工作的影响。

你可能认为这会导致很多集成问题，你可能是对的。但我们的想法是尽早解决集成问题，这通常是解决这些问题的努力最低的时候。

您需要有一些强大的持续集成来支持此方法。最好是具有良好的自动化回归测试覆盖率。

Answer 2

我强烈建议您考虑以下敏捷问题：

1. QA角色必须是您团队的成员(最好是对软件质量感兴趣的高级开发人员)。否则，QA将被视为一个外部服务，所以它不是很敏捷(参见Kent Beck的“极限编程解释”)。
2. Scrum Master应该强调这样一个事实，即使用分支工作不是问题，而正是针对这种情况的解决方案，在这种情况下，有许多QA和一组开发人员意味着Scrum Master必须确保每个模块都开发良好。要做到这一点，测试驱动开发是一个很好的策略来获得报告，如代码覆盖率、检查样式、copy+paste代码(CPD)和圈复杂度指数(以及其他)。
3. Scrum Master还应该考虑定义一个持续集成策略，以确保每个应用程序模块的更改不会影响当前版本或候选版本的预期行为。

敏捷方法不仅需要良好的源代码策略或管理；整个团队必须具有良好的导向、良好的同步和良好的动机。否则，您的项目将是成功的，但不是敏捷的。