Svn 具有连续集成的多个功能分支-部署

我们正在使用SVN进行开发，没有机会切换，因为我们所在的大公司不允许这样做

我们正在开发的客户机/服务器应用程序通过TeamCity每晚构建和部署，以便第二天用户/测试人员/开发人员能够测试最新的代码。由于系统的性质，必须部署一些部件才能进行测试。e、 g.服务器端部分、Swing GUI、需要存储在数据库中才能运行的新配置等

当每个人都致力于主干时，这是很好的。然而，在代码冻结并上线后，我们需要切换到不同的模型。我们正在考虑对每个特性进行分支，然后将几个分支合并回来，从而发布一个版本

这有助于保持代码的整洁，但是我们如何对每个特性进行手动测试呢？我们没有足够的硬件来部署每个功能分支。即使我们这样做了，测试也会很乏味，因为您必须登录到多个环境才能看到所有最新的功能

TeamCity是否可以从多个功能分支中自动合并一个临时分支

这是针对DVCSs提到的，因此实际上并不适用

我的其他选择是什么

---

让每个人都提交一个手动构建的开发分支，然后在准备好进入UAT时切利选择从那里到主干，然后激活，然后从主干创建一个新的开发分支，切利选择其他没有提交到UAT的分支？

CI中功能分支的一个流行解决方案是

把你的工作交给你的部门

让CI框侦听分支存储库以运行一组基本检查（编译代码、运行所有单元和组件测试、快速冒烟测试）

如果成功，将最新的从主干合并到您的工作副本中

如果合并成功且没有冲突，请将工作副本提交到主干

在trunk中的新候选版本上运行其余的集成和系统测试

这个想法是，你尽可能多地发布。将行李箱中的每件物品作为生产准备

这种方法的两个主要问题是：

具有支持功能分支的CI技术（否则您将为每个功能配置新的管道配置）

与Git等新工具相比，Svn合并可能有点麻烦。您只需要处理较小的更改集，经常从主干更新，并拥有较小的类

---

这里的合并步骤是手动的还是自动的？你将如何自动完成它？我假设在合并冲突时生成失败。我会首先尝试将其自动化，这取决于您使用的生成工具。如果发现冲突，则应引发生成失败。如果您在代码提交之前从主干更新功能分支，那么管道中合并冲突的概率应该会降低。您最终使用了什么解决方案？我发现自己的处境与你描述的相似。我现在正在从事的项目已经与SVN进行了几年基于主干的开发，最近刚刚开始通过TeamCity和Web Deploy（.net mvc Web app）进行基本的CI/CD开发。管理层现在想开始做独立的功能分支，我正在寻找最佳实践。