由多个独立供应商开发的分布式系统经过实践验证的 SVN 结构是什么?
假设一个系统具有例如三层(UI、服务、数据)和它们之间的服务合同:每一层由几个组件组成,这些组件由不同的供应商开发,这些组件不依赖于特定的层,例如供应商 A 为 UI 和服务开发组件层和供应商 B 为服务和数据层开发组件。
每个供应商应仅对其自己的组件具有写访问权以及对所需服务合同的读访问权。
-> 在这种情况下构建 SVN 的好方法是什么?
按供应商?按层?两个都?... ?
由多个独立供应商开发的分布式系统经过实践验证的 SVN 结构是什么?
假设一个系统具有例如三层(UI、服务、数据)和它们之间的服务合同:每一层由几个组件组成,这些组件由不同的供应商开发,这些组件不依赖于特定的层,例如供应商 A 为 UI 和服务开发组件层和供应商 B 为服务和数据层开发组件。
每个供应商应仅对其自己的组件具有写访问权以及对所需服务合同的读访问权。
-> 在这种情况下构建 SVN 的好方法是什么?
按供应商?按层?两个都?... ?
为清楚起见,我建议按层组织结构。这样,查看结构可以揭示组件之间的关系。即使客户(即供应商)的开销更大,或者为每个客户设置对存储库的访问权有更多的开销,这也是值得的,因为每个客户都会习惯于考虑项目的整体结构,这将减少从长远来看,存在错误和 API 冲突的可能性。
在这种情况下,如果管理人员有自己的方式,他们可能倾向于按供应商分隔存储库。作为程序员,你知道得更多。将一些工作交给经理,以确保遵守正确的工作流程实践——为了清晰和更好的编程。
此外,只是让不同的供应商在同一个结构中看到彼此的工作,以这种小方式,鼓励互动(无论多么小)。再次,这是一种开放和沟通的努力,比安全和限制更重要。如果您一开始就作为程序员说,那是一个机会。
顺便说一句,Git 优于 SVN。
您需要将供应商分开,因此需要在那里进行隔离。每个供应商组件的主干对此很有意义。
在最近的一个主要软件项目中,我们允许每个供应商拥有自己的存储库,并对其他供应商具有读取权限。然后,我们使用触发脚本创建了一个只读合并主干。这些每天在午夜运行。
然后,合并后的主干由Jenkins构建环境拉动,该构建环境进行回归和系统集成测试,在每天开始时将故障和问题反馈给开发团队。
如果这些供应商真的是独立的,那么我不建议将所有这些组件保存在一个 SVN 存储库中。我宁愿为供应商提供单独的 SVN 存储库,并通过明确定义的发布流程与公共工件(类 Maven)存储库之间的控制合同和交互。例如,Nexus具有限制哪些工件可供哪些用户使用并允许控制读/写的能力。