How do our developers test SVN python branches with Jenkins?

Question

I am working on a web project with 7 developers. I am installing a beta version (debian) so that we can test the new code before passing it on to the stage.

In the beta block, I configure Jenkins and would like to automate the merge / test process. We also have a test suite that I would like to somehow relate.

How to check and run python web projects using SVN / Jenkins?

I am trying to formulate a good workflow. Now every developer works on a function branch, I run the code in the branch, if it looks good, we combine it.

I would really like the developers to go to beta-jenkins and tell what needs to be built from their branch of functions. Here is my plan for Jenkins:

• Make sure the function branch is reinstalled from the trunk
• Make sure the beta branch is identical to the trunk (overwrites any branches of the combined function)
• Merge function branch into beta branch
• Kill a running server
• Launch the nohup python app.py & server
• Run python test.py test suite python test.py
• Bring test data to developer view in Jenkins
• If any of the tests failed, return to the state before merging the branch.

I am not sure how to handle merge conflicts. In addition, the above is probably bad and wrong. Any advice would be appreciated!

Answer 1

The question is too large to be answered in a simple letter, so I will try to give some tips and links, as far as I can see from my personal opinion:

A few quick tips:

• I like the idea of ​​separating the developers from the branches, but I would do the testing on the function branch and only merge with the beta branch if the function passes the tests, so nothing introduces the beta version until it is tested!
• I would put integration steps in a script outside of Jenkins. Make it part of the source code. This way you can quickly test the script outside of Jenkins
• Use an assembly language or a scripting language with which you feel most comfortable, most of the steps can be easily done with any programming language.
• Make the script a successful or unsuccessful return, so Jenkins might mark the build as unsuccessful.
• For merge issues, you have two options
  • To require the branch to be manually reinstalled before the developer can send it for integration, check the script and will not work if reinstallation is required. Thus, merge-errors cannot occur, the assembly simply fails if the branch is not reinstalled
  • If you prefer non-repetitive merges, you need to compromise the assembly on merge errors so that the developer can manually solve the problem (reloading his branch before sending)

Here are a few books that I have found useful in this area:

• Like Google Tests Software, James A. Whittaker, Jason Arbon, Jeff Carollo
• Continuous Delivery: Reliable software release by automating the assembly, testing, and deployment of Jez Humble

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

Answer 2

There are a few things:

• At the suggestion of barracel - it would be much more convenient to use some DVCS - such a git is much better prepared to work in several branches.
• The IMHO merge process is something you probably don’t want to automate (I write about this, referring to “how to handle merge conflicts”). In the workflows that I used to work - the merger was always handled by a person, sometimes with some kind of code review (I'm not sure what you mean by “if it looks good” - you only check the functionality, as well as how it was implemented to have orientation?
• In addition to unittests - perform some functional tests (Selenium), as well as performance tests (jmeter or tsung), launched after each merge with the beta branch - this way you will also monitor how the application changes with development (and, possibly, reacts over time - for example, if you notice a decrease in performance on the login page, for example.
• This is trivial, but while working on separate branches - make sure the flow of information is to avoid the growth of the same parts in different branches, or growing conflicting in the used solutions / templates / libraries. What can help is sending error messages (to the developer who failed), and to everyone after the successful merger with the trunk - so everyone will be informed (but make sure that you do not send spam to the developers - they will stop reading it;)
• If you really have a lot of merge conflicts - maybe it's time to review the flow and minimize the number of branches, interesting readings http://lostechies.com/derickbailey/2010/02/24/branching-strategies-the-cost-of-branching -and-merging / or abstraction branch http://paulhammant.com/blog/branch_by_abstraction.html/
• Make sure that developers often pull and merge the trunk into their branches - this should also help with reducing conflicts or even
• Why not test directly on the branches of developers after merging with the chest? Such a combined code, again, should be easy to merge back into the trunk