SVN Development and Release Process - Sanity Check

Question

I am creating a process for working with version control and my web based application. This is what I have so far:

1. I am doing main development under branches/development and keep that in sync with my development server for testing.
2. I use svn:externals to bring the Zend Framework into my project. I use the revision number from the tag of the release I'm interested in. For example, the 1.10.5 Release is at revision 22306, so my svn:externals looks like this:
   • -r 22306 http://framework.zend.com/svn/framework/standard/trunk/library/Zend/ Zend
   • -r 22306 http://framework.zend.com/svn/framework/extras/trunk/library/ZendX/ ZendX
3. I merge tested, stable code from branches/development to trunk and create a version tag from that. I then release the revision made by that tag to my production server.

I don't really have a plan for hotfixes yet, but I'm thinking I can work off the production tags for situations like that.

I'm brand new at using Subversion, so please let me know if I'm overlooking something, or doing something that's going to bite me in the ass.

Thanks!

Sassoon

so that's what the externals are for!!! :) – Drupelet

Answer 1

You have a better process than most people. THe company I work for now does exactly the same thing with the exception that they create new production branches (version 1.01.1, 1.01.2 etc) instead of version tags like you're using (due to the scripts we use).

The only thing you need to make sure of is if you can roll back easily in the case of a failure. What I like to use is sim links. So when I 'deploy' to production I do a fresh checkout of the version I'm deploying, update the simlink apache points to to point to the new version and test it. If I have a problem I update the link back to the last working copy which would still be checked out on the server. Instant roll back. If you have that problem solved you're good to go IMHO.

Mechanical

Unfortunately, I do not have command line access to my web server, so I can't do symlinks. I am using Beanstalk - beanstalkapp.com for my Subversion hosting and they have a great tool for pushing releases to the web server. It allows me to pretty quickly revert to a previous revision. – Sassoon

Then that sounds good. You have your process pretty down. As a response to some of the above comments I prefer to have branches for teams/projects that they commit to and then leads merge into trunk after full QA testing (based on revision numbers of closed tasks/bugs). IMO trunk should always represent a stable production release. I think you're on the right path with this. – Mechanical

Answer 2

Your approach sounds fine but you could also just do your development in trunk and tag it when it is tested and stable. I'm not sure what you are gaining by using a separate branch for the main development.

Sidelight

I saw it recommended by several people. Keeping a stable trunk is supposed to scale better with larger teams. I started as you suggest, but saw wisdom in this other process, so I changed. – Sassoon

@Sassoon If the team is large it can make sense to develop certain features in branches and do things like bug fixes in trunk or in another branch. This gives the option of making a release that contains fixes but not features that are still in development. However if the team is small and you don't think you'll want to omit any code in progress to make releases you can just do the development in the trunk. You can change from one approach to the other as the situation changes. – Sidelight

Good point about changing approaches. Subversion makes it pretty simple to do so! – Sassoon