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!

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.