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
next 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).