[Catalyst] Cache of unchanging content

[Pedro Melo]

Hi,

On Wed, Mar 2, 2011 at 5:49 PM, Tomas Doran <bobtfish at bobtfish.net> wrote:
> On 2 Mar 2011, at 17:27, Pedro Melo wrote:
>> On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran <bobtfish at bobtfish.net> wrote:
>>> Installing to production servers via rsync / unison is insane, as there
>>> is
>>> exactly no way of knowing what version the production server is on, with
>>> what bugs...
>>
>> Of course you can. You can include a file .version at the root created
>> with 'git describe --always' > .version before you rsync, and then
>> include it on your test reports.
>>
>> Rsync is a valid deployment method, specially if you use a stage
>> server where you make install you app.
>
> Ah, but then you're deploying a specific sha1 from git, rather than just
> rsyncing a directory!
>
> And as you'll have a script to ensure that you have reset --hard MYSHA1
> (otherwise you are perfectly screwed just as I described), then you can put
> the build parts in there...

Actually the complete workflow is to push to our production repo, and
then run a script to publish a particular SHA1 to production. That
will git pull in the stage server, create a release branch, and then
run all the deploy scripts (minification of JS, CSS, and whatever is
needed.).

Everything is committed to the release branch and the new sha1 from
that is the one actually used on production servers.

Right now, thats a git reset to the release-sha1, and then a rsync to
production servers. I'm actually considering git pull's directly from
the production servers. Git is actually more effective than rsync,
given that it can calculate pretty easily which files changed between
versions.

Having git workdirs in the production servers has the extra advantage
of a easy way to revert bad releases, at least from the code
perspective. Reverting DB schemas is much more interesting.

Bye,
-- 
Pedro Melo
http://www.simplicidade.org/
xmpp:melo at simplicidade.org
mailto:melo at simplicidade.org