4 ms·

Deploying Stuff With Git

6 points by ojosilva 15y ago

lobster_johnson 15y ago
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
pyman 15y ago
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_management_systems http://en.wikipedia.org/wiki/List_of_software_package_manage...
- lobster_johnson 15y ago
  This has nothing to do with package management. It's about deploying web applications.
  - pyman 15y ago
    A web application is a software. How do you think we've been deploying software for the last 20 years, using FedEx?
    - lobster_johnson 15y ago
      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).

6 points by ojosilva 15y ago

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

pyman 15y ago

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_management_systems http://en.wikipedia.org/wiki/List_of_software_package_manage...

lobster_johnson 15y ago
This has nothing to do with package management. It's about deploying web applications.
- pyman 15y ago
  A web application is a software. How do you think we've been deploying software for the last 20 years, using FedEx?
  - lobster_johnson 15y ago
    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).