On Mon, Jul 23, 2012 at 12:23 AM, Sitaram Chamarty <sitar...@gmail.com> wrote:
> 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.
>> 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 ;-)
After a couple of false starts, I think that Sitaram came closest to
what Darek was asking about.
Now, as somebody who is using Git currently to stage things to
"deployment" (I may change to SVN due to office politics--which will
double my workload on rollout of updates, but I'm not saying any more
than that in public) on production web servers, I have a few comments.
We have several WordPress instances @$work where we are using Git to
stage template changes out to our development server (where I've
contemplated putting the lessons in Sitaram's article to use) before
merging those changes back into the "Production" branch (after
suitable testing) and pulling them from a central gitolite into the
live server. It works and it respects the posix extended ACLs on the
destination host (which is what you actually want on a live web
server). Even better, it provides a safe way of tracking and merging
back in any "opportunistic" changes that were made directly in the
development or production servers so that they are not lost.
Thought must be applied to do this safely, but that's the way it
usually is on web servers. To those who say admins should be using
RPM, DEB, or any other "generic package management" software to deploy
non-system updates to in-house web servers may I kindly indicate that
it often doesn't make sense to do so unless each and every website has
its own server and IP address--and you are deploying tens of thousands
of them. Most of us can't afford that. (Yes, there is an overhead to
building packages. I've done it enough times to know about that quite
Packages and package management are great for system software but they
are not a good solution for installing client code into a webspace on
a shared server (yes, heresy, I know). For this common use case Git is
not a half-bad ADDITION to the toolkit of a website development and
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
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