SVN在分布式开发中 - 最佳实践？

Question

由几个独立供应商开发的分布式系统的实际证明的SVN结构是什么？

假设一个系统，例如，它们之间有三层（UI，服务，数据）和服务合同：每层由几个组件组成，这些组件由不同供应商开发，不依赖于特定层，例如：供应商A开发UI和服务层的组件，供应商B开发服务和数据层的组件。

每个供应商只应具有对自己组件的写访问权以及对所需服务合同的读访问权。

- ＆GT;在这样的设置中构建SVN的好方法是什么？

供应商？按层？都？ ......？

Answer 1

为清楚起见，我建议按层组织结构。这样，查看结构揭示了组件之间的关系。即使客户端（即供应商）有更多的开销，或者设置每个客户端访问存储库的更多开销，这也是值得的，因为每个客户端都习惯于考虑项目的整体结构，这将减少从长远来看，可能存在错误和API冲突。

如果管理人员按自己的方式行事，他们可能倾向于按供应商分开存储库。作为程序员，你知道的更好。将一些工作放在经理身上，以确保遵循适当的工作流程实践 - 为了清晰和更好的编程。

此外，只要让不同的供应商在同一个结构中看到彼此的工作，就会以这么小的方式鼓励互动（无论多么小）。这又是一种开放和沟通的努力，比安全和限制更重要。如果你在一开始就说是程序员，那就是一个机会。

顺便说一句，Git优于SVN。

Answer 2

您需要将供应商分开，因此需要隔离。每个供应商组件的主干都有意义。

在最近的一个主要软件项目中，我们允许每个供应商拥有自己的存储库，并具有对其他存储库的读取权限。然后，我们使用触发脚本创建了只读整合主干。这些都是每天午夜运行。

然后，整合的主干由Jenkins构建环境提取，该环境执行回归和系统集成测试，在每天开始时将失败和问题发回给开发团队。

Answer 3

如果这些供应商真的是独立的，那么我不建议将所有这些组件保存在一个SVN存储库中。我宁愿通过明确定义的发布流程向供应商提供单独的SVN存储库，并通过公共工件（Maven-like）存储库控制合同和交互。例如，Nexus具有限制哪些工件可供哪个用户使用并允许控制读/写的功能。