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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
