My intention is to have the Rails app on a separate server from the Hudson server and have the Rails app return Hudson-friendly XML from RSpec and Cucumber tests. When i get this to work, it’ll enable me to roll this out at work, with a central Hudson server (perhaps) that interacts with multiple app servers of various technologies and, along with the wonders of Sonar, gives a view into code test coverage, pass rate and complexity. I feel that i might struggle convincing Sonar to play with Ruby, but we’ll see.

Why Hudson?

To be completely honest, at work, i didn’t make that decision and am yet to chase down exactly why it was chosen over CruiseControl, but I completely trust those that made the decision on their project. I’m a big believer in standardising and am as such following suit and trying out Hudson.

After a little thought and partially effective googling, i found that the following is an efficient process:

Introduction – What I had

• trunk
• branch_a created at SVN revision 2111
• branch_b created at SVN revision 2113

Step 1 – Preparation – Checkout local copies of trunk, branch_a, and branch_b

1. cd ~/
2. svn co http://svn_repository/trunk ./trunk
3. svn co http://svn_repository/branches/branch_a ./branch_a
4. svn co http://svn_repository/branches/branch_b ./branch_b
5. I ensured that all changes had been committed to trunk and both branches

Step 2 – Merging branch_a back to trunk after a successful rollout

1. cd ~/trunk
2. svn merge http://svn_repository/trunk http://svn_repository/branches/branch_a
3. svn commit -m “merged branch_a into trunk”

Step 3 – Merging the newly updated trunk into branch_b

1. cd ~/branch_b
2. svn merge http://svn_repository/trunk -r2113:HEAD .
3. svn commit -m “merged up from trunk, applying changes between 2113:HEAD that included changes made on branch_a”

Step 4 – When i’m ready, i’ll merge branch_b back into trunk, following Step 2 above

That’s it!