How should our devs test python SVN branches with Jenkins?

The question is a bit too big to be answered in a simple post, I will therefore try to give a few hints and references as far as I see from my personal view:

A few quick tips:

• I like the idea of separating the developers into branches, but I would do the testing on the feature-branch and only merge to the beta branch if the feature passes tests, this way nothing enters beta until it is tested!
• I would put the integration steps into a script outside of Jenkins. Make it part of the source code. This way you can test the script itself quickly outside of Jenkins
• Use the build-system or scripting language you feel most comfortable with, most of the steps can easily done with any programming language
• Make the script return success or failure, so Jenkins can flag the build as failed
• For the merge-issues, you have two possibilities
  • Require the branch to be manually rebased before a developer can submit it for integration, check in the script and fail it if a rebase is necssary. This way merge-errors cannot happen, the build simply fails if the branch is not rebased
  • If you rather allow non-rebased merges, you need to fail the build on merge errors so the developer can manually resolve the problem (by rebasing his/her branch before submitting again)

Here some books that I found useful in this area:

• How Google Tests Software, by James A. Whittaker, Jason Arbon, Jeff Carollo
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble

Let me know via comments what additional content you would like to have.

There are few things:

• As barracel suggested - it would be much more convenient to use some DVCS - such git is much better prepared to work in the multiple branches.
• IMHO process of merging is something which you rather don't want toautomate (I write about this referring to 'how to handle merge conflicts'). In workflows which I used to work - merge was always processed by human, sometimes with some kind of code review (I am not sure what do you mean by ' if it looks good ' - do you verify only functionality or also how it was implemented to have an orientation?
• Besides of unittests - make some functional tests (Selenium) and also performance tests (jmeter or tsung) launched after every merge to beta branch - in that way you will be tracing also how application is changing with the development (and maybe react in time - for example if you will notice decrease of performance during login page, for instance.
• It is trivial thing, but during work on separate branches - make sure about flow of the information so you will avoid developing same parts in different branches, or growing contradictory in used solutions / patterns / libraries. What may help - sending emails with fails (to developer who failed) and to everyone after successfully merge to the trunk - so everyone will be informed (but make sure that you are not spamming developers - they will stop reading it ;)
• If you really have a lot of merge conflicts - maybe it is time to reconsider flow and minimize number of branches, interesting readings http://lostechies.com/derickbailey/2010/02/24/branching-strategies-the-cost-of-branching-and-merging/ or Branch By Abstraction http://paulhammant.com/blog/branch_by_abstraction.html/
• Make sure that developers are pulling and merging trunk to their branches often - it should also help with reducing conflicts, or even
• Why not test directly on developer branches after merging from trunk? Such merged code, once again should be easy to merge back into the trunk