Is there a legitimate reason NOT to use SVN for production deploys, or is this merely a case of personal preference and there is no real case against SVN?
My workplace has a culture of tagging release in SVN and then deploying those releases directly to the various web servers using
svn co or
svn switch including directly to production.
I personally have a problem with this as I believe that without using a build and deploy script or some form or automated deploy you lose integration environment settings as they're undocumented. However more than that I have a gut feeling that there may be a hidden danger to doing that which has been overlooked, something which has yet to rear its ugly head.
I've brought up my concerns with the operations staff who are responsible for deploying code to our various environments (staging, pre-prod, production) etc. Their arguments were pretty much that it's worked pretty well so far, no reason to change.
What I mean about build and deploy:
For example, if a developer requires a web.config setting added for a particular environment. Web.config is generally not kept in svn and so these files are updated manually without any form of automated build script. So if they're lost or OPS forget to add a field to the web.config for a release then you have issues.
A build script that say uses XMLPoke to automatically generate a web.config appropriate for a particular environment is ideal in that you have a versionable script which documents all changes necessary for each of your environments.
Current Build and Deploy Method
For the project in question a developer builds a release manually, other projects have the build step automated either with NANT, or MSBuild which is OK.
Database migrations for most projects are via DB scripts, or migration scripts (Migrator.NET), or CMS Packages.
CI is usually done by Team City on a per checkin basis, we have a code review process that all tickets are done in branches and then peer reviewed for validation and correctness/quality prior to checking into trunk (works well).
However actual code deploy is pretty much always via SVN, either via a checkout of a tagged release or more generally an SVN Switch. This is something that sticks odd with me that we're using our repository as part of the deploy process.
Configuration doesn't generally change very often, the only things that will be in config files are environment specific information. Everything else is in the db.
Don't get me wrong this works, it works well. However I want to try and push for an automated build and deploy. I've used this with Rails and Capistrano, and for personal projects using Cygwin, Nant and SSH.
More importantly I would need very specific valid arguments to get my colleagues to change to using an Automated build and deploy.
Or are there NO real valid arguments against using SVN specifically to deploy to production?