What is your favorite web app deployment workflow with SVN?

Question

We are currently using a somewhat complicated deployment setup that involves a remote SVN server, 3 SVN branches for DEV, STAGE, and PROD, promoting code between them through pa

Answer 1

I haven't had any trouble with the common tags/branches/trunk organization.

General ongoing development happens in trunk.

Maintenance of a release in production happens in the appropriate release branch.

Changes to release branch which are still relevant to trunk are merged.

When a new version is ready for deployment it is tagged from trunk, then a branch is created from that tag. The new release branch is checked out to the server, parallel to the current release. When it's time to switch, the paths are juggled ("mv appdir appdir.old && mv appdir.new appdir").

Developers supporting the production release then svn switch their working copy to the new branch, or do a fresh checkout from it.

Answer 2

A simple trunk branch contains the most current code, then cut a branch whenever we go live. This seems to work pretty effectively. You can easily go to the previous branch whenever the current branch that you cut for the live system fails. Also, it is easy to fix bugs on the branch that is currently live, and since the branch effectively dies when you cut a new one, there is only ever 1 real branch you need to work on (and then merge fixes from there to the live branch).

Answer 3

Trunk contains the current "primary" development codebase.

A developer will often create an individual branch for any medium to long-term project that could hose the trunk codebase and get in the way of the other devs. When he's complete he'll merge back into trunk.

We create a tagged-release every time we push code to production. The folder in /tags is simply the version number.

To deploy to production we're doing an SVN Export to Staging. When that's satisfactory we use a simple rsync to roll out to the production clusters.

Answer 4

We use release branching - this seems to be more efficient for us than the feature branching we were doing.

Don't make different branches for the different environments.

Answer 5

We don't use branches for staging web-related stuff; only for testing experimental things that will take a long time (read: more than a day) to merge back into trunk. The trunk, in 'continuous integration' style, represents a (hopefully) working, current state.

Thus, most changes get committed straight to trunk. A CruiseControl.NET server will automatically update on a machine that also runs IIS and has up-to-date copies of all the extra site's resources available, so the site can be fully, cleanly tested in-house. After testing, the files are uploaded to the public server.

I wouldn't say it's the perfect approach, but it's simple (and thus suitable for our relatively small staff) and relatively safe, and works just fine.

Answer 6

trunk for development, and a branch (production) for the production stuff.

On my local machine, I have a VirtualHost that points to the trunk branch, to test my changes.

Any commit to trunk triggers a commit hook that does an svn export and sync to the online server's dev URL - so if the site is stackoverflow.com then this hook automatically updates dev.stackoverflow.com

Then I use svnmerge to merge selected patches from trunk to production in my local checkouts. I have a VirtualHost again on my local machine pointing to the production branch.

When I commit the merged changes to the production branch, again an SVN export hook updates the production (live) export and the site is live!