Re: Using git for code deployment on webservers?

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 16, 2009, 17:49 UTC
Message-ID: <alpine.LNX.2.00.0906161332080.2147@iabervon.org>
In-Reply-To: <200906160111.47325.ioe-git@rameria.de>

On Tue, 16 Jun 2009, Ingo Oeser wrote:

Show 29 quoted lines

> [please CC me, as I'm not subscribed]
> 
> Hi there,
> 
> I try to use git in a quite unusual way.
> 
> I have a bunch of servers (hundreds), which get regular pulls of web developer code.
> The code consists of images, flash files, scripting language files, you name it.
> An exported repo (just the files, no SCM metadata) contains up to 4GB of files.
> 
> No I want to distribute changes the developers made in a tree like structure:
> 
> main server --> slave_1 --> webserver_0815
>             |-> slave_2 --> webserver_2342
>                         |-> webserver_4711
> 
> But with the following contraints:
> - Store as little as possible on the webservers.
>   One selected revision/tag is enough.
> - Transfer as little as possible data.
>   Cancel out addition and deletion on the fly.
> - Nearly atomic update of file tree (easy to implement outside git)
> 
> Nice to have:
> - Instead of copying the files to their proper names, 
>   hardlink them to their git objects.
> 
> At the moment I always get more data than I need and have to store
> the repository AND the checked out data.

You should be able to have the slave repositories store tags for tree objects (instead of commit objects), and have the webservers fetch those. You'll still have the object database, but it will only contain stuff that's been deployed to that webserver, not intermediate versions or historical versions. You'll still have to store both the repo and the checked out data (but git stores the content delta-compressed against each other in one big file, normally, so there really aren't files to hard link to.

Of course, the other possibility is to check out versions on the slaves, and rsync that to the webservers, which is probably the optimal method if you're not in a situation where you benefit from anything git does in transit.

	-Daniel
*This .sig left intentionally blank*