[Catalyst] Re: Deployment in practice

Devin Austin devin.austin at gmail.com
Fri Oct 9 21:12:14 GMT 2009


On Fri, Oct 9, 2009 at 3:08 PM, J. Shirley <jshirley at gmail.com> wrote:

> 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 l=
ose
> 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 ju=
st
> have to learn the tools sufficiently.
>
> -J
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>
>
I'm coming in late but deploying a tag from trunk/etc and "switching" the
production directory that nginx/lighttpd/apache is looking at is probably
the coolest thing ever.  You have a great deal of control when needing to
roll back, and a record of all previous tags/versions.
Anyway, my $0.02.

-Devin


-- =

Devin Austin
http://www.codedright.net
9702906669 - Cell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091009/db148=
f13/attachment.htm


More information about the Catalyst mailing list