http://qs321.pair.com?node_id=707611

mandog has asked for the wisdom of the Perl Monks concerning the following question:

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.

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

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 new to programming, Perl and Linux.

Our dream is a full-on Debian webapp policy 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)

Right now, my limited goals are, in order of importance:

  1. Finish by Tuesday 8:00am
  2. Keep site specific code/templates completely separate from general code/templates
  3. Make it hard to avoid version control
  4. Take some advantage of standard package structure
  5. 5 minute install of development/testing copies on our server
  6. 30 minute install of development/demo on ubuntu 8.04 laptops
  7. 10 minute error-free updates of production sites
  8. (eventually) allow users to skin sites
  9. (eventually) package our work for other people to install under Debian/Ubuntu or at $10/month web hotels

An example advantage of standard packaging is to be able to easily run Devel::Cover

My draft plan is:

  1. migrate from cvs to svn
  2. use module-starter to create module-name-dir/
  3. svn move *.t and *.pm to module-name-dir/lib/ and module-
  4. add our webapp specific dirs into module-name-dir/
  5. create apache and dns config to point webdirs to file dirs

If things, work as I plan:

I'm imagining a directory setup like:

/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 viewa +ble 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/ ....

While of course our t/ tests are getting better, I'm imagining hand testing at URLs like:

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/

Comments?