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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html