2012/7/23 Sitaram Chamarty <sitar...@gmail.com>:
> On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> mer...@stonehenge.com (Randal L. Schwartz) writes:
>>>>>>>> "Darek" == Darek Bridges <darek.brid...@me.com> writes:
>>> Darek> I use git for many things, but I am trying to work out the
>>> Darek> workflow to use git for deployment.
>>> Don't.
>> Yeah, "don't think 'git checkout' is a way to 'deploy'".  Using Git
>> as a transport measure is probably fine.
> You can also try
> http://sitaramc.github.com/the-list-and-irc/deploy.html.  Whether it's
> saying you *can* use git for deploying something, or you *can* but
> *should not*, or you *cannot*, will depend on your own thoughts on the
> matter ;-)

Nice summary list of options!

If you combine that with several key concepts:
1. You plan and design to deploy - hence you have separate deploy
repositories dedicated for that
2. You design for modularity and complete audit trail, hence you have this:

You can combine the staging with any approach, that *tries* to
maintain the local version copy. But if any problem arises in
pull/fetch, simply trash that part and get it from fresh (or just use
the git archive approach).

Now this model would introduce complete and as detailed security
enforcement - as the deployment can validate with certificates (from
the additional catalogue-metadata binding, whether there is authorized
party confirmed signature available for the wished deployable

I don't see much overhead in any of the steps here - and the
deployment is as detailed and as securely controlled as desired. With
just Git (and well, possibly GnuPG or alike common tool for digital
certificate work).

Everything is also transparent - which is very important in having
that complete control and audit trail.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to