Re: recipe to use git for deployment

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 5/4/2012 11:10 PM, Marc Weber wrote:
> I always did "git pull" on the servers - but the history of my projects
> is not that huge.. Thus I never cared.
> Great: You can keep some server specific config settings and rebase
> them -
So I could rebase apache virtual host conf files with generic template 
changes like symlink support, but keep the networking ip's.  Merge 
conflicts would be bad.  I guess that would be cause to reset --hard to 
a previous commit.

and you can do a fast git status to check whether file contents
> have been modified (eg determine whether you've been hacked ..)
>
With 'source is run' like html, css, etc. that would be a good way to 
enforce no-hacking-allowed support agreements.

> If you really care that much about history why not push a zip file using
> git archive --format=zip and unpack that on the deployment server
> instead?
>
That is what I'm currently doing.  By paying attention to tracked 
executable bits I don't even have to fix permissions on deployment.

The scriptable patching of a git repo (scripted checkout of remote 
tracking branch commits to worktree with inserted conversions and 
validations -- an interactive cherry-pick so to speak) allows for 
flexible conversions of varying patch levels.  Maybe git-sequencer will 
do this when it comes out.

Also, I could have a deployment tracking repo on one of my servers that 
remotes to all deployed servers and pulls to refresh my monitor view of 
all deployed revisions in gitk.

> For FTP access only this did a great job for small projects:
> https://github.com/MarcWeber/git-ftp (->  git-ftp-minimal.sh)
> It only copies changed files *and* checks whether they have been
> modified on the server first (detecting work of others).
> But that's probably not a good thing for automatic deployment.
>
I'll take a look to see what I can steal, uh I mean reuse.  Thanks!

v/r,
neal