我们的开发人员应该如何在Jenkins中测试Python SVN分支？
我正在和7个开发者一起做一个网页项目。我搭建了一个测试环境（使用debian），这样我们可以在把新代码放到正式环境之前先进行测试。
在这个测试环境上，我安装了Jenkins，想要自动化合并和测试的过程。我们还有一个测试套件，我想把它也整合进来。
我该如何用SVN和Jenkins来测试和运行Python网页项目呢？
我正在想一个好的工作流程。目前每个开发者都在自己的功能分支上工作，我会运行这个分支里的代码，如果看起来没问题，我们就合并它。
我希望开发者能登录到测试环境的Jenkins，然后告诉它从他们的功能分支构建。以下是我计划让Jenkins做的事情：
- 确保功能分支是从主分支更新过来的
- 确保测试分支和主分支是一样的（覆盖任何合并进来的功能分支）
- 把功能分支合并到测试分支
- 停止正在运行的服务器
- 启动服务器
nohup python app.py & - 运行测试套件
python test.py - 把测试结果输出到开发者在Jenkins中的视图
- 如果有任何测试失败，就恢复到合并前的状态
我不太确定如何处理合并冲突。另外，上面的做法可能不太好，也可能是错的。任何建议都非常欢迎！
2 个回答
3
这里有几点建议：
- 正如barracel所说，使用一些分布式版本控制系统（DVCS），比如git，会更方便，因为它更适合处理多个分支。
- 在我看来，合并的过程最好不要自动化（我指的是“如何处理合并冲突”）。在我之前的工作流程中，合并总是由人来处理，有时还会进行代码审查。我不太明白你所说的“如果看起来不错”是什么意思——你是只检查功能，还是也关注实现的方式？
- 除了单元测试，还要做一些功能测试（可以用Selenium）和性能测试（可以用jmeter或tsung），这些测试在每次合并到beta分支后进行。这样你可以跟踪应用程序在开发过程中的变化，及时反应，比如如果你发现登录页面的性能下降。
- 这虽然是个小事，但在处理不同分支时，要确保信息流通，避免在不同分支上开发相同的部分，或者在使用的解决方案/模式/库上产生矛盾。一个好办法是，发送失败通知邮件给出错的开发者，并在成功合并到主干后通知所有人，这样大家都能及时了解情况（但要注意不要给开发者发太多邮件，他们会不再关注的；）
- 如果你真的遇到很多合并冲突，也许是时候重新考虑工作流程，减少分支的数量。可以看看这些有趣的文章 http://lostechies.com/derickbailey/2010/02/24/branching-strategies-the-cost-of-branching-and-merging/ 或者关于抽象分支的 http://paulhammant.com/blog/branch_by_abstraction.html/
- 确保开发者经常从主干拉取和合并到他们的分支，这样也有助于减少冲突。
- 为什么不在开发者的分支上直接测试合并后的代码呢？这样的合并代码应该也能轻松地再合并回主干。
3
这个问题有点复杂，不太适合简单回答，所以我会从我个人的角度给出一些提示和参考。
以下是一些快速建议：
- 我觉得把开发人员分成不同的分支是个好主意，但我会在功能分支上进行测试，只有当功能通过测试后才合并到测试分支。这样，测试没通过的功能不会进入测试阶段！
- 我会把集成步骤放在Jenkins之外的脚本里，把它作为源代码的一部分。这样你可以在Jenkins之外快速测试这个脚本。
- 使用你最熟悉的构建系统或脚本语言，大部分步骤用任何编程语言都能轻松完成。
- 让脚本返回成功或失败的结果，这样Jenkins就可以标记构建为失败。
- 关于合并问题，你有两种选择：
- 要求在开发者提交合并之前手动进行rebase（重新基准），在脚本中检查，如果需要rebase就让它失败。这样就不会出现合并错误，分支如果没有rebase，构建就会失败。
- 如果你更倾向于允许不进行rebase的合并，那么在出现合并错误时需要让构建失败，这样开发者就可以手动解决问题（在再次提交之前进行rebase）。
这里有一些我觉得在这个领域有用的书：
- 《谷歌如何测试软件》，作者：James A. Whittaker, Jason Arbon, Jeff Carollo
- 《持续交付：通过构建、测试和部署自动化实现可靠的软件发布》，作者：Jez Humble
如果你想要更多内容，可以在评论里告诉我。