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