我们的开发人员应该如何使用Jenkins测试python SVN分支？

Question

我正在与7位开发人员合作开展一个网络项目。我设置了一个beta框（debian），以便我们可以在将新代码传递给分段之前对其进行测试。

在测试版盒子上，我设置了Jenkins，并希望自动化合并/测试过程。我们还有一个测试套件，我想以某种方式配合它。

我应该如何使用SVN / Jenkins测试和运行python web项目？

我试图制定一个好的工作流程。现在每个开发人员都在一个功能分支上工作，我在分支中运行代码，如果它看起来很好我们合并它。

我很乐意让开发人员登录beta jenkins，并告诉它从他们的功能分支构建。以下是詹金斯将要做的计划：

1. 确保功能分支已从主干
重新定位
2. 确保beta分支与trunk相同（覆盖任何合并的功能分支）
3. 将功能分支合并到测试版分支
4. 杀死正在运行的服务器
5. 启动服务器nohup python app.py &
6. 运行测试套件python test.py
7. 将测试数据输出到Jenkins的开发人员视图
8. 如果任何测试失败，请恢复到合并分支之前的状态

我不确定如何处理合并冲突。此外，上述可能是坏事和错误。任何建议将不胜感激！

Answer 1

问题有点太大，无法在一篇简单的文章中回答，因此，就个人观点而言，我会尝试提供一些提示和参考：

一些快速提示：

• 我喜欢将开发人员分成分支的想法，但我会在功能分支上进行测试，只有在功能通过测试时才会合并到beta分支，这样在测试之前没有任何内容会进入测试阶段！
• 我会将集成步骤放到Jenkins之外的脚本中。使其成为源代码的一部分。这样您就可以在Jenkins之外快速测试脚本本身
• 使用您认为最舒服的构建系统或脚本语言，大多数步骤可以使用任何编程语言轻松完成
• 使脚本返回成功或失败，因此Jenkins可以将构建标记为失败
• 对于合并问题，您有两种可能性
  • 要求在开发人员提交分支以进行集成之前手动重新分配分支，检查脚本并在需要变基数时将其失败。这样就不会发生合并错误，如果分支没有重新定位，构建就会失败
  • 如果您更愿意允许非重新组合合并，则需要在合并错误的构建上失败，以便开发人员可以手动解决问题（通过在再次提交之前重新设置他/她的分支）

这里有一些我认为在这方面有用的书：

• Google如何测试软件，作者：James A. Whittaker，Jason Arbon，Jeff Carollo
• 持续交付：Jez Humble通过构建，测试和部署自动化发布可靠的软件

请通过评论告诉我您想要的其他内容。

Answer 2

有几件事：

• 正如barracel建议的那样 - 使用一些DVCS会更方便 - 这样的git可以更好地准备在多个分支机构中工作。
• 恕我直言合并的过程是你不想要的 自动化（我写这篇文章指的是'如何处理合并冲突'）。在我以前工作的工作流程中 - 合并总是由人工处理，有时会进行某种代码审查（我不确定你的意思是'如果它看起来不错' - 你只验证功能或它是如何实现的有一个方向？
• 除了单元测试之外 - 在每次合并到beta分支之后启动一些功能测试（Selenium）以及性能测试（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/
• 确保开发人员经常拉动并将主干合并到他们的分支机构 - 它还应该有助于减少冲突，甚至
• 为什么不在从trunk进行合并后直接在开发者分支上进行测试？这样的合并代码，再一次应该很容易合并回主干