版本控制和网站分支
我们有一个基于版本控制（SVN）的 Web 应用程序。 主干始终包含网站的最新版本。
我想听听其他团队如何管理同一网站的多个版本，以及你们如何发布不同版本以进行 UAT、测试、错误修复、增强等？
假设我们的商业用户出现了，他们想要一个全新的功能……所以我们要做的就是建立一个新的分支来进行我们的开发。 我应该如何发布分支而不影响主开发网站。 我们应该将网站的每个分支发布到唯一的端口吗？
http://DevServer:80 = 中继
http://DevServer:8081 = 分支 001
http://DevServer:8082 = 分支 002
http://DevServer:8083 = 分支 003
http://DevServer:8084 = 分支 004
显然，我们必须将项目文件部署到 unqiue 目录中，如下所示好吧，并正确映射 IIS...
这是一种常用方法吗？ 最佳实践是什么？
We have under version control(SVN) a web application. The trunk always contains the latest good version of the website.
I would like to hear how other teams manage multiple versions of the same site and how do you publish different versions for UAT, testing, Bug fixing, enhancements etc?
Let's say our biz users come along and they want a spanking new feature...So what we do is set up a new branch to do our dev. How should i publish the branch without affecting the main dev website. Should we publish each branch of the website to unique ports?
http://DevServer:80 = Trunk
http://DevServer:8081 = branch 001
http://DevServer:8082 = branch 002
http://DevServer:8083 = branch 003
http://DevServer:8084 = branch 004
Obvisouly we would have to deploy the project files to unqiue directories as well and have IIS mapped correctly....
Is this a common method? What are the best practices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
理想情况下，您应该为每个环境（生产、uat、测试、开发和ci）运行单独的机器。 如果您没有实际物理机的资源，那么虚拟化是非生产环境的最佳选择。
这也意味着您可以正确测试您使用的各种依赖项和库的效果。
编辑：关于分支...
我们在这里以及我之前工作过的几个地方所做的就是在主干上建立一个集成分支。 开发新功能的开发人员从集成分支中分支出来并重新集成到集成分支中。 CI 在集成和主干上完成。 可以对集成进行非正式测试，但更正式的测试（UAT 版本）来自主干。 我们定期从集成分支向下集成到主干。 这还有保护躯干的额外好处。
IE
Ideally you should be running a seperate machine for each environment (production, uat, test, dev & ci). If you don't have the resources for actual physical machines then virtualization is the way to go for the non-production environments.
This also means you can properly test the effects of the various dependencies and libraries which you use.
EDIT: About branching...
What we do here, and in a couple of places I've worked before is have an integration branch off the trunk. Developers developing new features branch off the integration branch and reintegrate into the integration branch. The CI is done on both integration and trunk. Informal testing can be done on the integration, but more formal testing (UAT releases) come from the trunk. Periodically we integrate down from the integration branch into the trunk. This has the added benefit of protecting the trunk.
i.e.
RedBean 书（免费）对分支进行了精彩的描述。 尽管本书针对的是 SVN，但分支策略描述适用于所有情况。
另一个很好的免费资源是 Microsoft Team Foundation Server 分支指南 白皮书。 它涵盖：
The RedBean book (free) gives an excellent description of branching. Although the book targets SVN, the branching strategy description applies to all.
Another good free resource is the Microsoft Team Foundation Server Branching Guidance whitepaper. It copvers:
将不同分支部署到不同端口是一种解决方案，在 Java servlet 环境中，将分支映射到不同路径的解决方案会更容易（我不知道 IIS 是否也是如此）
两种解决方案都应该运行良好。 如果没有其他要求，我会选择使用所用技术更容易设置和维护的解决方案。
To deploy the different branches to different ports is one solution, in the Java-servlet-environment the solution to map the branches to different paths would be easier (I don't know if that is true for IIS too):
Both solutions should work well. If no other requirements I would choose the solution that is easier to setup and maintain with the used technology.