[Catalyst] Distributing and updating Cat apps
bogdan at sinapticode.ro
Fri Apr 9 19:10:17 GMT 2010
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
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:
INCLUDE_PATH = __path_to(root)__
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.
More information about the Catalyst