On Fri, Apr 9, 2010 at 4:11 PM, Bill Moseley <mose...@hank.org> wrote: > > > On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale > <toby.corkind...@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 _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/