Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Baby step to proper packaging

by mandog (Curate)
on Aug 28, 2008 at 22:01 UTC ( [id://707611] : perlquestion . print w/replies, xml ) Need Help??

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:

  • code can be made live by running  svn update
  • new developers can get started with a svn checkout and a line appended to apache / bind config files
  • people can run on laptops with apache config changes to point to localhost

I'm imagining a directory setup like:

/var/www/ sites/ # site-01/ module-name-dir/ .... site-01/ .... developers/ betty/ mandog/ module-name-dir/ # +/ cgi-bin/ # web viewa +ble conf/ etc/cron.d/ app.conf.template etc/apache2/conf.d/ .... doc/ install on laptop lib/ project-bin/ bin/ .... setup/ create-schema.sql 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:



Replies are listed 'Best First'.
Re: Baby step to proper packaging
by tilly (Archbishop) on Aug 28, 2008 at 22:57 UTC
    I'm not sure what your actual question is. So I'll make random comments.

    While I prefer subversion over CVS, that's not a high priority. If time is short I would leave that to last, and not make it first.

    I think it is a bad idea to try to release through svn update. I would say that a high priority should be a defined release process which includes having development, staging and production environments. Code should be moved from development to staging, tested there, then released to production. When you release to production you want to release what was put on staging, and not what is current.

    If you want to make people use source control, the best approach is to deliberately and regularly overwrite production files with files from source control. Get management on board with this. Then when you do so it won't be your fault for having broken someone else's change, it will be their fault for having not used source control. If you can't get agreement on this point, then source control is a lost cause and you should be looking for a better job. (The fact that they are letting you accomplish an important work project on your own time over a long weekend is frankly a pretty bad sign...)

    Rather than have one Apache file for all of the development sites, I would suggest having one copy of Apache per development site, each of which is on a different port. You can then let every developer check out the source code on their own user account. This will require development-specific configuration information. I've used several approaches for this in the past. A simple one is to have a well-defined configuration file which is per server and is not in source control.

    This is the core that you need. Your other changes can and in my opinion should be treated as an ongoing project. I would recommend not biting off too big a refactoring job up front. It is better to finish something useful than it is to not finish something big.

Re: Baby step to proper packaging
by jbert (Priest) on Aug 29, 2008 at 09:31 UTC

    Your plan to use module-starter is good.

    However, once you have a module, you can go further and use dh-make-perl to easily create a .deb from it.

    which is a pretty nice way of doing the distribution.