Development model for website using SVN

2
votes

I'm working on an intranet website for my company and currently am using SVN as version control mainly using the 'trunk' for all development. Big new features are developed in branches and merged to trunk later on.

However recently we decided to first make all and any changes available on a designated test server, give everyone a week time to test/validate these changes, and then make them available on the production server if there are no objections/bugs found.

Leaving the branches and development model out of scope for now, this gives me 3 different 'environments' that have to coexist:

  • Development
  • Test
  • Production

The problem is that I'm contiously developing in trunk, when a chunk is finished, I want to activate this on the test server, then after a week when it's validated, I want to activate it on production as well.

This is the idea I've come up with, but I'd like to get some feedback on whether this is the right way to go.

The idea is to keep doing 'regular' development in the trunk, and use feature branches for big changes which will then later on be merged into the trunk, no changes here. Then I'll make 2 copies of the trunk, one to branches/test and one to branches/production. Then everytime I commit something to the trunk, I can cherry-pick-merk it first to test and later to production. This allows me to merge some changes to production while holding of other which might not be approved yet on test.

Is this a good way forward? Thanks in advance!

1
web-servicessvnversion-control

1 Answers

0
votes

This is how we have it set up: We develop on the trunk. Our dev work is on our local laptops, and when it works well enough, we check in. Then we deploy on the trunk to the Development Server, and do a bit of testing there.

We deploy to the Test server also on the trunk, but only after we see it working on the Dev server, and NOT if the code in Test has been approved for prod.

So Dev is the most recent checked in, and Test is often that recent too, but sometimes it is an older revision. Both of these are on the Trunk.

When the code in Test is approved for Prod, we will create a tag, then deploy the tag to a copied app, make sure that the source code matches what we expect, and then deploy that tag-created application to Prod.

If the code in Test which has finally passed QA isn't the very latest in the trunk, we just create the tag off the revision number.

We don't often use branches, as we like to deploy everything at once. But there have been times we have used branches for major features - and there are tools for integrating when it is all ready.