perlquestion
mandog
<p> We have a medium sized web application that is about 40 .pl and .pm files, not counting core & CPAN modules. It is running on exactly one site. The users like it. They'd like instances running with different (and maybe overlapping) data on 2 more domains. </p>
<p>Our packaging is lame. We were: falsely lazy, under some pressure to “just get it done”, learning Perl, originally just doing one instance of this app and working with artistic managers. Also, the dog ate our homework</p>
<p> For example, only the original developer trusted the home-brewed installer. As a result people copy files by hand or (ugh!) modify production files in place. We're a tiny group, right now just me. At times we have as many as 3 people working on the project. Usually the people working on the project are <em><b>new to programming</b></em>, Perl and Linux.</p>
<p>Our dream is a full-on <a href="http://webapps-common.alioth.debian.org/draft/html/">Debian webapp policy </a>compliment package. Sadly, history repeats. Management is much less artistic but the world still pressures us to be falsely lazy. I've got until Tuesday 8:00am to make general infrastructure improvements. (Then the priority is filing tax reports with the IRS)</p>
<p> Right now, my limited goals are, in order of importance: </p>
<ol>
<li> Finish by Tuesday 8:00am</li>
<li>
Keep site specific code/templates completely separate from general code/templates
</li>
<li> Make it hard to avoid version control</li>
<li> Take some advantage of standard package structure </li>
<li> 5 minute install of development/testing copies on our server </li>
<li> 30 minute install of development/demo on ubuntu 8.04 laptops </li>
<li> 10 minute error-free updates of production sites</li>
<li>(eventually) allow users to skin sites </li>
<li>
(eventually) package our work for other people
to install under Debian/Ubuntu or at $10/month web hotels
</li>
</ol>
<p>
An example advantage of standard packaging is to be able to easily run <a href="http://search.cpan.org/dist/Devel-Cover/lib/Devel/Cover.pmhttp://search.cpan.org/dist/Devel-Cover/lib/Devel/Cover.pm">Devel::Cover</a>
</p>
<p>My draft plan is: </p>
<ol>
<li>migrate from cvs to svn</li>
<li>use module-starter to create module-name-dir/ </li>
<li>svn move *.t and *.pm to module-name-dir/lib/ and module- </li>
<li>add our webapp specific dirs into module-name-dir/ </li>
<li> create apache and dns config to point webdirs to file dirs</li>
</ol>
<p>If things, work as I plan:</p>
<ul>
<li>
code can be made live by running <code> svn update</code>
</li>
<li>
new developers can get started with a svn checkout and a line appended to apache / bind config files
</li>
<li>
people can run on laptops with apache config changes to point to localhost
</li>
</ul>
<p> I'm imagining a directory setup like: </p>
<code>
/var/www/
sites/
# http://site-01.org/
site-01/
module-name-dir/
....
site-01/
....
developers/
betty/
mandog/
module-name-dir/
# http://mandog.testing123.net/site-01/cgi-bin/site-01/
cgi-bin/ # web viewable
conf/
etc/cron.d/
app.conf.template
etc/apache2/conf.d/
....
doc/
install on laptop
lib/
project-bin/
bin/
create-pdf.pl
....
setup/
00setup.pl
create-schema.sql
load_special_data.pl
special_date.csv
update-schema-01.sql
update-schema-02.sql
update-schema-03.sql
t/
templates/
site-01/
conf/
app.config.template
app.conf
static/ # web viewable
index.html
site-01/
templates/
t/ # test w/ html tidy , link checker, etc
site-02/
....
site-03/
....
</code>
<p> While of course our t/ tests are getting better, I'm imagining hand testing at URLs like: </p>
<code>
http://localhost/site-01/
http://mandog.testing123.net/site-01/
http://mandog.testing123.net/site-02/
http://mandog.testing123.net/site-03/
http://site-01.org/site-01/
</code>
<p> Comments?</p>
<!-- Node text goes above. Div tags should contain sig only -->
<div class="pmsig"><div class="pmsig-91846">
<BR><BR><A HREF=mailto:dan@thecsl.org>email: mandog</A>
</div></div>