Setting up SVN to Best Suit Dev -> QA -> Prod

Question

I'm sorry if this has already been asked, but I haven't been able to find an answer specific to this situation:

For our web application, we have 3 systems: dev, QA, and production. Right now, a third party is maintaining the code, but soon it will be in our hands. We will have separate build environments for each stage. Also, we use RAD for code development, so there'll actually be a primary step, test/sandbox.

Ideally, we'd like to somehow isolate repositories for each stage, such that we check out from DEV, make some changes, test them locally, and check them back into DEV. If everything is ok on Dev, we will check into QA, and so on.

Should we have separate repositories for each, or would this fall under 'branching', where we'd have a separate branch for dev, QA, and prod. Could you also provide the best means of implementing whatever the ideal route is?

Let me know if there are any other questions, also.

Thanks Chris

Answer 1

You should have a single repository that can be checked out or exported during the deploy process.

We, too, have a similar setup. Developers check out a local working copy and develop in their dev environment. When we are ready to deloy to stage, or QA as you call it, we do an svn export to that environment (often of head, but we always keep track of the specific revision).

During the QA process, we continue to develop in dev and deploy to QA.

Finally, when we are ready for production, we export the right revision from the repository into the production environment.

Works great!

[Edit: as far as 'is this branching' - what you are describing is probably more like keeping track of revisions. branching is, however, a very important technique for managing different development lines. this should not be confused with having a different branch for each stage (dev, stage, live), necessarily]

Answer 2

use branching and merging

We do the following:

When we release we create a current release branch. We make bug fixes here between releases, then merge them back to our trunk.

We develop on trunk and when we are ready to release we make a QA branch. We test and fix on it and then push it out and it becomes our current release branch.

Answer 3

This works fine if you are working on a single stream of development with easily confirmed tasks. But it will prove more challenging with multiple streams of development and the possibility of the tasks being pulled out or delayed. You would then need some kind of time dependency within your application. You could also use something like feature branches which are merged back into the trunk once the feature is built.

Answer 4

Check out Scott Cowan's blog post:

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

He has a great article on promoting your code to different environments. It will include writing some build scripts but will improve the process. It will allow it to also be some what automated.

Answer 5

We've got similar schema. In SVN we have 3 branches, trunk, PREPROD and PROD. Whenever new feature is ready to try, it's get merged into the PREPROD branch (using only specific revision numbers and only for specific files), if it passes QA, it gets committed and merged into PROD branch. When changes get committed in PROD branch, they are automatically deployed in all production servers. Except for when testing new features, PREPROD and PROD are equal.

Answer 6

We have a development branch for each bugfix, feature or task, and involved projects tend to have multiple sub branches.

Initially it is kind of wierd creating a new branch for just a one line code fix, but it allows merging the trunk into the branch, then regression testing and finally merging back into trunk.

Ideally this means that anything merged into trunk will not break the build, and it means that you aren't scared of committing your code to make a fragile build.

I often use multiple branches for the one issue, testing out different solutions while still getting the benefits of SCM.

We also tag specific versions or releases, allowing quick deployment based off of known good code.

Alot of our web based systems use svn:externals that point to specific versions of dependencies such as libraries and vendor code. A deployment is taken from the externals, rather than a straight checkout or export.