Hacker News Reader

Comment by wvenable | Hacker News Reader

Subversion -- the website is a working copy of the production branch and I just do an svn update when changes need to be deployed.

The whole thing is wrapped up in a script that makes it possible to one-click deploy changes.

The biggest thing is the application is directory independent and auto-senses the host for database selection. This means that no changes are required to the application to run it in development, staging, or production.

Edit: Apache is setup so that no .svn directories are served. Given that most web applications go through a front-controller now, I'm hoping this isn't as much of a concern anymore.

View on HN

Just a word of advice to anybody using this approach - make sure to setup Apache(et al) to not serve .svn folders and files or someone will be able to download your code. I've always used a release shell script that does an svn export and just replaces the entire directory.

Or, better yet, don't put sensitive data in public web directories! Have your working copy somewhere else, and update your "svn update" script to also run an rsync with an --exclude=.svn to your web root.

Same here, not as nicely automated though (still need to actually type 'svn update').

What I really like is the ability to instantly roll back to any version.

Don't forget to block .svn directories in your apache config!

The other advantage is sometimes, in emergency situations, I've had to edit the production code directly on the server. It's nice to be able to see what's changed, commit if necessary, or rollback to the original production version.

umm, isn't that what svn export is for :)

why stop at .svn, how about .~, .bak, .tmp, .swp !

The problem with export is that you're deploying every single file. With svn update, you're only deploying the changed files.

We use Subversion as well. However, we use Ant scripts to do the build work. It makes updating our servers pretty straight forward.

My sites are PHP so building is limited but some things do need to be built. However, my sites effectively build themselves without the need for another tool. On the first access of a resource, if the target doesn't exist it's built by the code automatically and stored in a cache. During development, the cache is disabled so you can edit and run without any intermediate build step. Things built this way include parts of the ORM and output templates.

Same here, multiple sites. Using the same code base for dev/stage/production is a huge win.

Same here, but Mercurial instead of Subversion.

svn up

simple.

priceless.

Reply on news.ycombinator.com