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 patches, etc. I wonder what do you use for deployment in a small dev team situation?

Answer 1

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!

Answer 2

When i worked in a small dev team (small meaning me, another programmer and the boss), it was quite the chaotic mess. However we found that Assigning a "gatekeeper" type of process worked for us.

The gatekeeper was the person who had done the most work on the app (in this case, i had 2 projects i developed from the ground up, he had like 4).

Basically, whenever he had to work on my projects, he'd notify me that he was doing work, i'd make sure the repository was up-to-date and buildable, then he would pull down, make his changes, then commit. He would inform me that it was done, i would pull down, build and deploy. If there were DB changes we had a DB Change folder with all the scripts that would correct the DB.

It's obviously got a lot of holes in it, but the process worked for us, and kept us from building over each other.

Answer 3

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 4

Three branches just sounds like extra work.

Environmental differences can be handled by having different versions of the relevant files in the trunk. i.e. database.yml & database.yml.prod. The deployment process should be environmentally aware and simply copy the per-environment files over the default ones.