[Catalyst] Distributing and updating Cat apps

[Bogdan Lucaciu]

On Fri, Apr 9, 2010 at 4:11 PM, Bill Moseley <moseley at hank.org> wrote:
>
>
> On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale
> <toby.corkindale at strategicdata.com.au> wrote:
>>
>> 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?
> 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?
> What about your static content (css, js, images)?  Where do those get
> installed?

Considering a Catalyst app is laid out like any standard Perl
distribution, using dh-make-perl will generate a pretty standard
debian package, so all the stuff in script/ goes to /usr/bin/, and all
the other files go in /usr/share/perl5/Dist/Name.

To properly include the templates I would just use something like:
<View::TT>
    INCLUDE_PATH       = __path_to(root)__
...

or similar.
The static content lives in /usr/share/perl5/Dist/Name/root/static, if
you use a caching reverse proxy (like varnish) you can just let
Static::Simple serve them, otherwise just point your web server's
/static location to that dir.

Also, all the stuff produced by your application (uploaded file,
whatever) should go in the correct paths (as per FHS), like
/var/lib/app-name/ , /var/cache/app-name etc

About rollback, it's as simple as installing the old version, all is
replaced, but I don't know how you'd handle database schema changes (I
use Schema::Versioned a lot, it can probably handle the rollback, but
didn't try it so far)

> 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.

Handle all this logic from config files and env variables.
Take a look at http://www.catalystframework.org/calendar/2009/11

I would argue on keeping outside of the external config files
everything that is NOT related to configuration/deployment but is
INTERNAL to your application. For instance all the View::TT config
could very well be defined in TT.pm and kept in your code repo, while
the Model::DB DSN should be in the config file.



-- 
Bogdan Lucaciu
http://www.sinapticode.com