I was thinking on the way to work today that subversion would be a great tool to overcome some of the difficulties associated with frequent deployments to the web serevers. Here's how I see it working
Create a production/live build folder in your source tree and add it to the repository.
Modify our build system to create the live builds in this folder and commit to the repository.
On the live server the site is deployed as a checkout of the live build folder.
Once the build passes unit tests and QA all we need to deploy is to update the working copy on the live server. The big advantage here is that rollbacks etc. are automatically handled because we can always roll back to a previous version. Also you get a nice history of all the updates to the live server.
Thanks for the tip. This is really cool and very helpful in our case.
Paul, if you build the web.config handling into your build process (if you use ASP.NET, using Web Deployment projects), then you can use svn to deploy web.config and all.
We use subversion to update our integration / testing server and then run vice-versa between that and the production server, which very quickly moves only the files that have changed.
I use SVN to manage the the production environment for the company I work for. And although I don't use it currently I built a web interface for a past client that would allow them to update their production environment from an SVN repository. I used some classes from AnkhSVN for that solution.
Why would you want to deploy with all those SVN folders? Also, if it's a web application project why would you want to deploy with all the .file_extension.cs and .designer.cs files?
I can see how it could work but I prefer cleaner deployments.
- team checks code itno SVN
- build server with CCNet automatically checks for code updates every 10 minutes or so, rebuilds if code updates are found
- new builds are automatically deployed to DEV server
- on request, deploy of a specific build to INT(egration) server can be done
- ditto for PROD
Actually, code that's gonna be deployed to INT is branched first. So it's always a specific branch that is deployed to INT (or PROD), whereas the trunk is used for ongoing development (though we also use branches to develop things that can't be in the trunk yet).
We've actually written an interface where we can select which branch of which project needs to be deployed to which server in which environment.
Our customer facing site is 4 gigs with all the artifact files. We have 2 designs and 2 developers that belong to different departments and it was a nightmare to keep track of changes.
I (one of the developers) wrote a few tiny utils to parse svn logs and svn info to find files that were added, changed, deleted and using that info built nant scripts for each process. I zip up any files that have been added or changed from our working copy and run the nant script for those that were deleted.
I created a web interface for the designers so that after they commit a change they can hit the web interface, choose the revision number and start the deployment. The web interface also has an iframe that points to a local CC.NET, staging CC.NET and prod CC.NET. After they choose the revision they do a force build local which moves everything to staging. do a force built on staging to run a backup and deploy. after they test then do a force build on prod.
I also use subversion as a deployment tool to live sites (mainly pre-compiled Flash presentations/applications and PHP code). The staging and live sites are working copies and I update from a tagged online version. I love the efficiency of the process and the ease of use. Basically, every integrator in our office, junior and senior can update live sites without much worries (knowing that a rollback is just as easy).
I do admit that publishing to production with the added .svn folders isn't all that clean, but what's the cost of drive space versus the cost of inefficient processes?
Unfortunately for us, the person in charge of hosting architecture is bent on "compiling" the website when it comes to live deployment... I don't get it. Managing added files and folders is relatively easy, just a zipped package to upload. But what about renaming, deleting, and rolling back ? You'll have to script something to do the actual deletion and renaming... Subversion does that for you. You'll have to copy your entire site to be able to rollback ... ".svn" folders are probably lighter than a full duplicate all in all.
Is subversion a security threat? I just don't get it.
@Martin: Subversion isn't a security threat in and of itself as far as I know. The only problem is that, in general, a host of people have access to subversion, and most of the controls around subversion are procedural in most organizations - developers agree to commit to certain branches, etc, but they are not actively prevented from doing so.
This means that introducing broken code into "production" is relatively easy. Yes, it could be rolled back, but....
Keep in mind that the person in charge of hosting architecture is being held accountable for a functioning production system at all times. He's on hook to put process in place that aren't sufficiently controlled.
If you do want to use Subversion for managing production, I'd recommend talking to your head of hosting and asking what controls would be sufficient for him to feel comfortable using svn in production. Don't be surprised if this ends up needing a separate svn repo managed slightly differently than the dev repos.
I still do not have a clear idea of how you guys are using SVN for deployment.
In my environment, I have development and production servers. SVN repository is on the DEV server, every time we need to deploy to PROD, we push the changed files manually to the PROD servers. I can sync the Dev and Prod servers but there are a lot of unused files in Dev which should not go to Prod. Tagging seems to be one of the options in SVN but haven't tried it yet. Can you please advice?