Is it acceptable to deploy web app to production directly from SVN

Question

Question

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?

Background

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.

Edit:

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?

Answer 1

From my experience, there are both advantages and disadvantages:

Pros:

• Sometimes you make urgent hot fixes on the production server, then you can check them back in directly from there. (Although theoretically, for security reasons it's always a good idea to use read-only access to the repo from the production server.)

• Simplicity: you deliver quickly, although as others mentioned here, switching to an update-script scheme can be as easy.

Cons:

• Your system can become unstable during your svn up and DB updates. For a high-traffic site this means some users will hit error messages, broken pages or empty pages at best. Well, that's what we very often see on various social services. A good service, however, does it "atomically" in a sense that it puts the system into maintenance mode for the duration of an update. (You broke reddit!)

• Conflicts: resolving sudden conflicts on the productions server is a terrible idea: again, the service becomes unstable while you're fixing it.

• Unrelated files on the production server which may or may not belong to you, although of course you can avoid it by checking out the right subtree in the repo.

• Security: someone who gained access to your production server, legitimately or not, also gains access to your repos, possibly other products as well, and possibly also with write access! Overall opening up your internal SVN server to the outside world is a bad idea. Your source repositories should be behind a company firewall, period.

• There are going to be update scripts anyway, e.g. for updating the DB structure, managing cronjobs, etc, so why not having a script that does it all? - i.e. pulls the latest pre-packaged release, switches to maintenance mode, updates sources, runs release-specific scripts etc.

Edit: for those still on the SVN scheme, don't forget this in your apache config:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

Answer 2

I have set up a CI server at my work that automatically creates our installer assuming that the unit tests pass successfully. It took about a day of work and it has saved me much more than that since I set it up.

If there is any manual process in configuring your release/installer/production website then you will invariably save yourself and the company time. This is appropriate to you as from your question it looks like there are manual configuration steps in your setup process.

For a reference, see Joel himself talk about how a single click build process saves you in the short to medium term.

Answer 3

Ensure that you have the appropriate checkin controls on SVN. For example, consider this -

• Features are checked in for a release
• Code is deployed into staging, QA does its job
• Bugs are fixed, another round of testing (however it works in your team)
• Ditto for pre-prod
• Deploy to production

If somebody accidentally makes checkins after the pre-prod stage, there's a risk of breaking something. If this is controlled - as in no checkins allowed during pre-prod except for bug fixes - I don't see any risks.

Update: You have a problem waiting to happen if you don't checkin your configuration files. I can't really offer any advice for this other than "please do, and fast!"

Answer 4

It seems ok as long as there is nothing outside the repository. Infact, I believe one should not invest time in deployment tools the first few months of the project. Cause there will be too many deployments, not enough customers to be bothered about a formal release process.

But once the project is about a year old its worth considering investing in deployment tool. Simple reasons are

• Business grows so you plan to host it on more than one server
• There might be bugs on a particular environment and you dont have any place to replicate the bug. There is no easy way to set it up without a tar-untar-forget_about_home_for_a_week process.
• Some one is likely to break the build. Who broke the build

If you want to convince them, ask them to setup another server for internal testing or QA.