Recently I checked out Flickr’s versioning theory by Cal Handerson, so it is almost like my current deployment progress, but with some differences….
I’ve used on many projects Subversion. It works perfect combined with staging at 3 levels:
- dev
- staging (testing area)
- public area (the final, user visible web directory)
Working on 3 levels with PHP projects is almost perfect, except 2 things:
1. Web Tests
2. DB Changes
This is hard to be handled by SVN or CVS, but using a good PHP Framework with defined vartypes parameters on any of the controller & model, can do automatic testing and also we will need to write alot of web tests, but this is realy needed if we want to have a working app 
About the DB changes, there are alot of tools for mysql and any of the other RDBMSes, but in most cases they doesnt work as they has to (i mean generaly mysql or maybe i didnt found the right tool). So here is maybe a good idea to create an RDBMS backend seperated with an web app for creating changes to the DB, then we log them and add them to the SVN.
So in few words, how to finish all those ‘baby steps’ into a good version control system with testing:
1. When a new version is done in the dev we deploy it to staging.
2. When staging is deployed, we run web tests and automatic tests.
3. Run DB tests (sync cloned production db with the changes and verify its integrity)
4. If everything is ok….move to the public area
hi. i read your article. we are in the middle of selecting a versioning software. Our setup is exactly as you describe yours. we have played around with quite a few options and have failed to find anything that is a perfect fit.
Would you care to share how you deploy from deve to staging and so on.
deploying to dev is simple with shadow folders, but how do deploy to your staging box?
branches? triggers? a little info would be greatly appreciated.
Thanks
I don’t know what you mean in ‘shadow folders’, but using SVN is easy.
Just checking out the ‘dev’ folder in a temporary folder, clearing the current (old) ‘staging’, then checking out the temp folder to ‘staging’.
And we have a fresh ‘staging’ now and we can proceed to run tests and etc.
(with the same procedure we checkout the ‘staging’ to ‘public’ if we think that staging works OK).
This is for the SVN part. About DBChanges, we had developed an tool that reads db table information from XML files and then parses it. If they are changed (the XML files), we create Patches files that are recorded on the file space (later we sync it with SVN, for some reasons).
Another way of creating an DBChanges Version Control on the data in a dbtable is the usage of ‘audition’ observer, that looks around for ‘UPDATE’,'INSERT’,'DELETE’ and saves meta information in a DBTable or files. This is some kind of usable cos’ almost any information can be reversed to its parent version and this helps while the (web)application is in Beta version
About ‘branches’, yah they can be used after we get an working and stable version (all works in the `staging`), so we can copy the working version to an ‘branch’ with common version name.
PS: We can do a chat in Skype if you need more information and ofcourse If i can help somehow
my skype is: cheaser-r0x 
Lyubomir, how do you copy files from staging to the public area? rsync? Or do you checkout from SVN again?
Our public are is a working copy (with checkout) with an mod_rewrite option do deny access to .svn directories from users (via HTTP).
I think this is the fastest way to sync the public area, a large project ~60-70MB with alot of files can need 1-2mins for svn export, so checkout will fix only the changed files and the application will not hangout.
Other way of doing this is using svn export to temporary directory and after all files are exported, just use /bin/mv to move the files (you must 1st remove the old folder), but this will need time.
Depending on the site/application (public large scale web application, private (itranet) web site/application and etc..) type you can use other suitable ways of syncing. There are many other ways, but I think those are the most used ones.
Sounds similar to what we have done too. So do you check out all of the dev folder into the staging folder, because surely some things in the dev repository would still be in development, while others would be reading for staging. How do you manage this?
BTW, your comments script incorrectly labels me as using Safari, when I’m using Chrome
I think this is mostly Google’s fault as their useragent identifies itself as such in part:
http://www.google.com/chrome/intl/en/webmasters-faq.html#useragent
(switching to Firefox for this post)