[Catalyst] Distributing and updating Cat apps

[Toby Corkindale]

On 09/04/10 23:11, Bill Moseley wrote:
> On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale
>
>     We package things up into Debian-style packages, and then upload
>     those to a local repository of packages.
>     Then servers can just be updated using the standard system tools (apt).
>
> Hi Toby,
>
> This is really the direction I'm heading now (although it's looking like
> CentOS and RPMs).  Can you answer a few general questions?
>
> Are you using Template Toolkit?  How (or really where) are the templates
> managed?   Where do they get installed, how does the TT View know where
> to find them, etc?  Do they end up in /usr/share/<app>/ for example?

Yes, I'm using Template Toolkit, although due to the 
apparently-unfixable crashes in the XS stash, I've also built some 
packaged with Template Alloy too.

I just put my templates into the 'root' directory, as per the Catalyst 
standard layout. After installation, they end up under your distro's 
Perl directory, in site_perl or vendor_perl, under a 'root' directory in 
your Module's namespace.

Eg. if you have MyApp.pm, then your templates end up in
..../site_perl/5.10.1/MyApp/root/

> I'm sure you never have to roll-back a release, but I also assume you
> are prepared to roll-back if needed.  How does that process work?

If you're using the Debian tools, then you can specify a version number 
when giving a package to "upgrade", which can also be used to downgrade.
(This requires you to configure your company's local .deb package 
repository to hang on to N many old versions; how many for N is up to you.)

The debian tools seem really quite good at noticing if you've, say, made 
changes to the local configuration file for your app, but that there are 
also changes to it coming down in the new version, and it'll prompt you 
about this.

It's worth noting that by default, the debian package tools will put 
your myapp.conf into site_perl/5.10.1/MyApp/ as well.. I dislike this, 
and so over-ride the debian/rules file to move it into /etc/ where it 
makes more sense.

> What about your static content (css, js, images)?  Where do those get
> installed?

As above, under site_perl; however you can override this in the 
debian/rules files to put it in /var/www/ or somesuch; I'm lazy and tend 
to just use Static::Simple; if you have a reverse proxy in front of your 
app (as you should if performance is a concern) then you can just cache 
the static stuff there instead.


> Any special tricks when using an app in "development" vs. production?
>   (For example, under "dev" I use source css, js, but otherwise the app
> uses combined and compresses css and js.

When in development, I run it on a different server altogether, and do 
not have it installed into the global perl path at all. And I run it 
with the "myapp/script/myapp_server.pl" rather than via a standalone 
webserver+appserver(+ optional proxy) stack.

For your example, I would put the command to combine-and-compress the 
CSS and JS into the debian/rules file.

However you need a staging server which mirrors the production 
environment and stack in order to properly test it prior to release.


>     You have a choice of either packaging up every single Perl
>     dependency into a Debian package too (which is a world of pain), or
>     installing all your dependencies into a local directory that you
>     ship with the application. I recommend the latter.. (you'll still
>     need to include dependencies on things like the C libraries for your
>     database client, etc though, in the debian control file.)
>
>
> We are doing a mix.  But, for the most part we are creating single
> modules (packages).  Mostly that was to encourage inclusions of unit
> tests and just more fine-grained management.  But, it is more work, true.


I disliked having to use the relatively primitive and time-consuming 
Debian/Gentoo/RedHat tools to manage CPAN modules, when CPANPLUS exists. 
Why use a plastic trowel when you have a pneumatic digger available? :)

I should point out that this does then require keeping the entire 
installed Perl tree in source control though, so that one can tag 
exactly which modules were used (and bundled with) an application.


Toby