How do manage your Perl application development, build, and deployment?

Question

I have yet to come up with a satisfactory way to manage the development, build, and deployment of my Perl applications. I\'d like to hear how you have solved this problem and/

Answer 1

There's a lot that I could write about this

1. Control of libraries - I create my own versions of CPAN with just the modules I want. The latest versions of App::Cpan has several features, such as the -j option to load one-time configurations, to help with this. Once you have this, you can distribute it on a thumb-drive or CD which has all of the modules, the CPAN.pm configuration, and everything else you need. With a little programming you create a run_me script that make it all happen.

2. Makefile/Build integration - I don't integrate the Makefiles. That's the road to disaster. Instead, I do integration testing with the top-level application module, which automatically tests all of its dependencies too. The -t switch to the cpan command is useful to test the module in the current working directory:

   cpan -t .

There are various intergation testing frameworks that you can use too. You set PERL5LIB to something empty (with only have the core modules in the hard-coded @INC directories) so cpan has to install everything from scratch.

3. Version control friendly - it doesn't much matter what you use. Most things have some sort of export where you can get everything without the source control stuff. Git is very nice because it only has a minimum of pollution in the normal cases.

4. Cross platform - everything I've mentioned works just fine on Windows and Unix.

5. Single Perl install - this part is more tricky, and I think you're going in the wrong way. Any time multiple things have to depend on the same perl, someone is going to mess it up for the others. I definitely recommend not using the system Perl for application development just so you don't mess up the operation of the system. At the minimum, every application should install all non-core modules into their own directories so they don't compete with other applications.

6. Easy start up - that's just a simple matter of programming.

BONUS: I don't use Module::Starter. It's the wrong way to go since you have to depend what Module::Starter thinks you should do. I use Distribution::Cooker which simply takes a directory of Template Toolkit templates and processes them to give them your distribution directory. You can do anything that you like. How you get the initial templates is up to you.