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

Question

我的任务是为我们向敏捷的过渡提出一个 svn 结构，该结构必须扩展到多个团队（包含多个开发人员）。在与我的同事交谈后，我想出了下面的示例结构。我受到了其他团队成员的一些反对，他们有正当的担忧。当我们都必须共享一个 QA 环境时，我希望找出在多个团队中拥有 svn 结构的最佳实践。

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

在这一点上，我不知道该怎么做我们如何回应。我希望 SO 土地上的一些人/团队可以告诉我们他们的结构如何，以及由于您的结构而遇到了什么问题。

Answer 1

我建议您看看 Jez Humble 和 David Farley 的“持续交付”。他们详细介绍了分支策略，并专门讨论了 SVN。

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

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

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

Answer 2

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

1. QA 角色必须是您团队的成员（最好是对软件质量感兴趣的高级开发人员）。否则，QA 将被视为外部服务，因此它不太灵活（请参阅 Kent Beck 的“Extreme Programming Explained”）。
2. Scrum Master 应该强制执行这样一个事实，即使用分支不是问题，而是针对这种有大量开发人员的情况的解决方案。
3. 与一组开发人员一起工作意味着 Scrum Master 必须确保每个模块都开发良好。为此，TDD（测试驱动开发）是获取代码覆盖率、检查样式、复制+粘贴代码 (CPD) 和圈复杂度指数等报告的好策略。
4. Scrum Master 还应考虑定义持续集成策略，以确保每个应用程序模块更改都不会修改当前版本或候选版本的预期行为。

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