git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: git@vger.kernel.org
Subject: recipe to use git for deployment
Date: Fri, 04 May 2012 22:51:21 -0500	[thread overview]
Message-ID: <jo283q$kna$1@dough.gmane.org> (raw)

I'm trying to cook up automated mass deployment using git as the main 
ingredient.  Here's a recipe idea:

install git on deployed server under the home dir of the 'gittech' user 
and add that path only to the PATH of 'gittech'.

have the git repos on deployed server be under the 'gittech' home dir 
with worktree(s) assigned to deployment locations.  If people mess with 
the worktrees I will be able to tell with git status via 'gittech'.

I can ssh to deployed servers from a deployment server and do git fetch 
to get updates.

I can have a 'deployment manager' repo which contains script to apply 
patches from remote tracking branch to worktree.  It checks out commits 
at waypoints and at waypoint it executes needed file/data conversion 
programs, creates dir/file structures, etc.  If conversion validation 
program is successful it will continue to checkout next waypoint, etc, 
until worktree matches HEAD of remote tracking branch.

Data/files are commited to data tracking git repo at waypoints.  If 
waypoint validation fails then software version repo and data version 
repo are checked out to last good waypoint or back to startpoint.

Problem(1): cron patches.  The cron jobs portion I'm not sure of.  Need 
to learn more about cron.  Perhaps cron can run scripts that are 
symlinks to a worktree.  Cron worktree can have waypoints just like 
software and data worktrees.  The cron tabs, cron.daily, etc can be 
worktrees perhaps also.

Problem(2a): diskspace.  I think I will have to pull shallow clones to 
avoid growing history.  For deployment I only care about recent 
revisions.  Not sure if the above ideas will work with shallow clone.

Problem(2b): network latency.  Maybe I can have the git repo object 
store on the deployment server and the deployed git repo reference it to 
save diskpace on the deployed server.  That would probably be really slow.

I'm thinking the ingredients of this recipe could make a tasty git 
deployment.  Maybe different ways of mixing and cooking them and other 
ingredients can make a good dish.  Please let me know if you think this 
can be edible for security, palatable for reliability, and digestible by 
git.

v/r,
neal

             reply	other threads:[~2012-05-05  3:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-05  3:51 Neal Kreitzinger [this message]
2012-05-05  4:10 ` recipe to use git for deployment Marc Weber
2012-05-05  4:43   ` Neal Kreitzinger
2012-05-05  5:04     ` Marc Weber
2012-05-05  5:30   ` Neal Kreitzinger
2012-05-05 12:14     ` Sitaram Chamarty
2012-05-16 20:08       ` Neal Kreitzinger
2012-05-05  4:31 ` Junio C Hamano
2012-05-05  8:25 ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='jo283q$kna$1@dough.gmane.org' \
    --to=nkreitzinger@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).