Deploying Stuff With Git | Hacker News Reader

Deploying Stuff With Git

babyl.ca

6 pointsojosilva5 comments

Push and reset are not atomic, so you will risk race conditions this way: While Git is updating the local directory, a user may be visiting the site and will be loading files that are in different version states.

The only way to atomically deploy an application is to clone into a new directory and then write a symlink to point to the new directory. You can maintain a local Git cache that contains the newest tree and clone from that; Git uses hard links, so the clone will be fast. So something like:

    cd $cache && git fetch origin && git reset --hard $version && \
      git clone $cache $temp && ln -sf $temp $current

Of course, apps can be designed to avoid the race condition, by caching the application's files. Rails and Sinatra will do this (but only for Ruby files), for example. Edit Reply

Don't re-invent the wheel.

Package management systems blur the boundaries between operating system and software. Use them, please.

http://en.wikipedia.org/wiki/List_of_software_package_manage...

This has nothing to do with package management. It's about deploying web applications.

A web application is a software. How do you think we've been deploying software for the last 20 years, using FedEx?

A web application is not systems software. Back when web sites were pure HTML pages, were you deploying them as packages? How about PHP sites, do you deploy them as packages?

There is a chasm dividing OS management and app management. The OS is the province of sysadmins, but apps are the province of developers. Ideally you want to bridge the two by having the environment "contain" the app, in a way that lets an application be automatically deployed from the newest code (eg., from Git), coordinated by an external system (eg., Jenkins), running inside an environment controlled by the configuration management system (eg., Puppet).

Reply on news.ycombinator.com