我正在尝试为我们的 Sage SalesLogix Web 应用程序设置我的组织的源代码控制架构。我们正在使用 SVN。
我们有 3 台服务器，一台开发，两台用于用户验收测试，两台用于生产。每个环境都有自己的数据库。
我们希望保持主干井井有条，但是在按照 SalesLogix 想要的方式管理 VFS 时这可能会很困难。
我想做的是： - 让所有开发人员在 App Arch 中使用 SalesLogix 的 DEV 安装实例。- 将更改部署到本地机器以进行本地单元测试和审查。- 完成所有开发工作后，创建一个包含提议修订中的所有更改的包。- 一个构建管理器在 UAT 安装实例上安装包。- 编译并部署到 UAT 文件夹。- 拒绝时，卸载捆绑包并在更改后重新安装。- 接受后，对生产服务器执行相同操作，并提交更改。
虽然这意味着我们有 3 个 VFS，但这意味着我们只开发一个，对我来说，这是要走的路。
我的想法是否正确？
老实说，我没有将 SVN 用于 SalesLogix 模型，而是专门将 Git 与 SalesLogix 一起使用。这是因为 Git 的工作方式更适合 SalesLogix 和 Application Architect 的工作方式。在正常情况下，SCM 无关紧要，但对 SalesLogix 则有影响。并不是说 SVN 不能很好地与 SalesLogix 模型一起使用，我知道有些人将 SVN 与 SLX 一起使用（它不像 Git 或 Mercurial 那样容易），但老实说，除了偏好之外，SalesLogix VFS/模型实际上只适用于完全分布式的 SCM。
也就是说，您所描述的是我如何在 Git 中使用 SalesLogix。我工作创建一个开发分支并在那里完成我所有的工作。master 基本上反映了生产中的内容，因此如果需要，我可以随时从 master 重新部署到生产中。在 dev 分支中，我进行所有开发并为特定功能创建功能分支。然后在功能完成时合并回来。通过这种方式工作，您可以在将所有内容移至生产工作分支之前对其进行开发和测试。一旦准备好部署，我就可以轻松切换到生产分支，然后从那里进行部署。如果 QA 拒绝了事情，只需切换回生产分支或在需要时回滚提交即可。此外，以这种方式工作，您实际上只需要一个 VFS 或模型。
然而，尽管如此，我仍然维护与生产分开的开发和测试系统（主要是因为我作为 SLX 业务合作伙伴而不是 SLX 客户工作），否则您无法测试交付的捆绑包。在开发系统中，我使用上述分支来允许我在新功能开发仍在进行时将修复程序发布到生产环境中。
我希望我能为您提供更具体的 SVN 信息，但无论使用何种 SCM，概念都是相同的。