Question

I am working on a web project with 7 developers. I setup a beta box (debian) so that we can do testing of new code before passing it to staging.

On the beta box, I setup Jenkins and would like to automate the merge/testing process. We also have a test suite which I would like to tie-in somehow.

How should I test and run python web projects with SVN / Jenkins?

I’m trying to formulate a good workflow. Right now each developer works on a feature branch, I run the code in the branch, if it looks good we merge it.

I would love to have developers login to the beta jenkins, and tell it to build from their feature branch. Here is my plan for what Jenkins would do:

1. Make sure the feature branch is rebased from trunk
2. Make sure the beta branch is identical to trunk (overwriting any merged-in feature branches)
3. Merge the feature branch into the beta branch
4. Kill the running server
5. Start the server nohup python app.py &
6. Run the test suite python test.py
7. Output the test data to the developer’s view in Jenkins
8. If any of the tests fail, revert to the state before the branch was merged

I’m not sure how to handle merge conflicts. Also, the above is probably bad and wrong. Any advice would be appreciated!

Answer 1

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.