[Catalyst] Re: Deployment in practice

[J. Shirley]

On Fri, Oct 9, 2009 at 1:18 PM, kevin montuori <montuori at gmail.com> wrote:

> >>>>> "MA" =3D=3D Mesdaq, Ali <amesdaq at websense.com> writes:
>
>  MA>  Once it passes the tests the code can be merged into the
>  MA>  production branch and will auto deploy.
>
> That's a great solution until someone checks a change into the
> production branch accidentally.  As someone already mentioned, it'll
> happen eventually.
>
> I'm a firm believer in not using version control as a deployment tool.
> It's more work to create a package, deploy that to test, test, deploy
> *the same package* to production, but you at least know that what you
> tested is what's in production.  Pulling straight from VC you never
> really have that assurance.
>
>
A lot of these assertions are pretty much FUD.

Even exporting a tarball is sourcing from version control.  You're just
bypassing a lot of the built-in aspects of source control and applying
manual steps that can be messed up in a variety of ways.

Unless it is sourced from source control in a way you can easily and
programmatically detect, you really don't know what is in production
outside of "a tarball".    You can keep an archive of tarballs, but you lose
context and history... so what's the win?

If something happens and you need to find out the history, what do you do?
You ask version control!

There are plenty of ways to manage how things get into a production branch.
Then, you simply add in another layer using tags.  After all, that's pretty
much why tags exist, and how they're used, in every sufficiently modern
system.

You deploy a tag, from a branch, and everybody wins.

Keep in mind that I'm not advocating (nor are the posts I linked to) running
from a -managed- tree.  The post-update hook I linked to keeps its own git
repository to itself, it isn't share.  You have to explicitly push to it to
update.

These things are very hard to get wrong, and they work very well.  You just
have to learn the tools sufficiently.

-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091009/2927b=
552/attachment.htm