我正在与7名开发人员一起进行一个web项目。我设置了一个测试箱（debian），这样我们就可以在将新代码传递到暂存之前对其进行测试。
在测试版上，我设置了Jenkins，并希望自动化合并/测试过程。我们还有一个测试套件，我想以某种方式与之搭配。
我应该如何使用SVN/Jenkins测试和运行python web项目？
我正在努力制定一个好的工作流程。现在每个开发人员都在一个功能分支上工作，我在分支中运行代码，如果看起来不错，我们将其合并
我很想让开发人员登录到测试版jenkins，并告诉它从他们的功能分支构建。以下是我对詹金斯的计划：
- 确保功能分支已从主干重新建立基础
- 确保beta分支与trunk相同（覆盖任何合并的功能分支）
- 将功能分支合并到测试分支
- 杀死正在运行的服务器
- 启动服务器
nohup python app.py & - 运行测试套件
python test.py - 将测试数据输出到Jenkins中的开发人员视图
- 如果任何测试失败，请恢复到合并分支之前的状态
我不知道如何处理合并冲突。此外，上述情况可能是糟糕和错误的。任何建议都将不胜感激！
这个问题有点太大了，无法在简单的帖子中回答，因此我将尝试从我个人的角度给出一些提示和参考：
一些快速提示：
- 我喜欢将开发人员分为多个分支的想法，但我会在功能分支上进行测试，只有在功能通过测试时才能合并到测试分支，这样在测试之前就不会进入测试分支
- 我会把集成步骤放到Jenkins之外的脚本中。将其作为源代码的一部分。通过这种方式，您可以在Jenkins之外快速测试脚本本身
- 使用您最熟悉的构建系统或脚本语言，大多数步骤都可以使用任何编程语言轻松完成
- 使脚本返回成功或失败，这样Jenkins就可以将构建标记为失败
- 对于合并问题，您有两种可能性
- 在开发人员提交分支进行集成之前，要求手动重新建立分支的基础，签入脚本，如果需要重新建立基础，则使其失败。这样就不会发生合并错误，如果分支没有重新建立基础，那么构建就会失败
- 如果您更倾向于允许非基于基础的合并，则需要使基于合并的构建错误失败，以便开发人员可以手动解决问题（通过在再次提交之前重新建立其分支的基础）
以下是我发现在这个领域有用的一些书：
- 《谷歌如何测试软件》，作者：James A.Whittaker，Jason Arbon，Jeff Carollo
- 持续交付：通过构建、测试和部署自动化实现可靠的软件发布
通过评论让我知道你想要什么其他内容。
有一些东西：
- 正如barracel所建议的那样——使用一些DVCS会更方便——这样的git可以更好地在多个分支中工作
- IMHO合并过程是你不想做的事情automatic（我写这篇文章时提到"如何处理合并冲突"）。在我过去工作的工作流中，合并总是由人工处理，有时还需要某种代码审查（我不确定你所说的"如果它看起来不错"是什么意思），你是只验证功能，还是验证它是如何实现的
- 除了单元测试之外，还可以进行一些功能测试（Selenium），以及在每次合并到beta分支后启动的性能测试（jmeter或tsung）。这样，您还可以跟踪应用程序如何随着开发而变化（并可能及时做出反应），例如，如果您在登录页面时注意到性能下降
- 这是一件微不足道的事情，但在处理单独的分支时，要确保信息的流动，这样你们就可以避免在不同的分支中开发相同的部分，或者在使用的解决方案/模式/库中变得矛盾。可能有帮助的是-发送失败的电子邮件（给失败的开发人员）和成功合并到主干网后的每个人-这样每个人都会得到通知（但要确保你没有向开发人员发送垃圾邮件-他们会停止阅读；）
- 如果你真的有很多合并冲突——也许是时候重新考虑流量并尽量减少分支数量了，有趣的阅读http://lostechies.com/derickbailey/2010/02/24/branching-strategies-the-cost-of-branching-and-merging/或抽象分支http://paulhammant.com/blog/branch_by_abstraction.html/
- 确保开发人员经常将主干线拉到分支并进行合并——这也有助于减少冲突，甚至
- 为什么不在从主干网合并后直接在开发人员分支上进行测试？这种合并后的代码应该很容易再次合并回主干中