<br><br><div class="gmail_quote">On Thu, Apr 1, 2010 at 12:51 AM, Toby Corkindale <span dir="ltr"><<a href="mailto:toby.corkindale@strategicdata.com.au">toby.corkindale@strategicdata.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>
We package things up into Debian-style packages, and then upload those to a local repository of packages.<br>
Then servers can just be updated using the standard system tools (apt).<br></blockquote><div><br></div><div>Hi Toby, </div><div><br></div><div>This is really the direction I'm heading now (although it's looking like CentOS and RPMs). Can you answer a few general questions?</div>
<div><br></div><div>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? </div>
<div><br></div><div>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?</div><div><br></div><div>What about your static content (css, js, images)? Where do those get installed?</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.)</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div><br></div></div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>