Claudio Ramirez raised a perceptive question about the Modern Perl book, specifically How do you deploy a modern Perl application?
I can think of several approaches:
- As a simple program which uses only core modules and relies on the system Perl.
- As a distribution on the CPAN itself.
- As a distribution on a custom, private CPAN.
- As a custom CPAN repository.
- Through the platform native packaging system.
- As a tarball of all of the dependencies installed already.
- Through the use of PAR.
- Through the use of a proprietary tool such as
perl2exe. - Installed manually with a custom build of Perl (whether with or without perlbrew).
- Through the use of another dependency management and bundling system such as Shipwright.
- As a service, not an installable application.
Have I missed any?
Under which circumstances would you choose one over another?
Is this subject appropriate to discuss in the book?
I think this would be a great subject for the book...
Deployment system we came up with recently...
Deployment system we came up with recently...
I find it convenient to divide deployment into horizontal and vertical modes.
Horizontal deployment is within an an administrative domain and vertical deployment is between them.
Within an administrative domain you can take advantage of lots of other tools such as rdist, rsync nfs and the automounter. Typicaly these all depend on common authn and authz.
Another approach is to make direct use of features of the revision control system where the deployment directory is maintained by tracking a particular revision tag.
A third approach exploits clever nfs and automounter configurations to control what applications are available on which nodes in the administrative domain.
None of these are exclusively horizontal or exclusively vertical, but each lends itself better to one mode or another. Those techniques which depend on common AAA base are more flexible horizontally, while those that bundle components into a single "blob" are more flexible vertically.
And obviously these techniques are typically layered, even within a single administrative domain. For example a central "master" system could be maintained using a more vertical technique such as cpanm, PATH control and a custom perl install per architecture. Within the LAN clients gain access to appropriate configurations via automounter maps and NFS. A Remote location would have "secondary masters" that are synchronized using say rdist over the WAN. This system then acts as an NFS server to systems on their local LAN.
Lots of different approaches. No single one is right.
As always, choices of techniques need to balance convenience and reliability. as well as address command, control and operational readiness.
I think the question of a smooth deployment comes up more often today than in the past, so I'd definitely think it worth considering. I also always felt that the toolchain in Perl is a very solid and good one. But one thing I find very important, and often ignored, is continuous deployment. What happens after the app was once setup? Processes and data might have to be migrated, and I feel Perl's very strong in that regard (at least at the data part of it).
Definitely a good topic for book! Did anyone ever wrote about Perl programs deployment in a book?
HI cromatic,
I see a lot of similarities between your project and PBP. First, the aim to get rid of "old school" Perl by proposing a modern, perlish alternative (even if PBP precedes "modern" Perl). Most importantly, I see the Modern Perl book having a similar revitalizing effect on the community, a true rallying point. I am sure that both books will be side-by-side in a lot of bookshelfs of Perl hackers.
Why deployment? Because after writing beautiful, effective and modern Perl, you need to deploy it. Often in production environments were no longer the sole admin or developer calls the shots. We may need to take suits into consideration that have been conditioned to only hear Java or .Net. Hundreds of servers as target (with different Operating Systems and Perl version, often obsolete) and complex network architectures complicate thing. When the deployment is taken from the hands of the developers -as it should be-,it's even more crucial to have a straight-forward deployment process.
The beginning -and even the advanced- Perl developer needs more than a few pointers on how to proceed to have a secure and transparent way to deploy (read: upgrade) his application. Once more experienced, more complex and customized options are possible. In the mean time, best practices and a few simple and easily reproduced scenarios are needed.
Please don't get me wrong, this is not a critique of the book. Due to the importance of this project, I care about making it better.
Perl is well integrated in FreeBSD. When a third party perl module is installed (understand a perl module that is not present in FreeBSD ports), it is automatically transformed into a FreeBSD package, on the fly, by a layer called BSDPAN. BSDPAN is integrated with the perl distribution available in ports or via FreeBSD packages.
So it is easy to manage perl modules, CPAN ported ones, CPAN manually installed ones or DarkPAN ones, as easy as installing/deleting another FreeBSD package.
No need to install the latest perl release, as the FreeBSD perl team is very reactive. For example at the moment, users have choice to install 5.8.9, 5.10.1 or 5.12.1 versions, with threading enabled or not.
Using the native packaging system is very useful! Believe me :)
One of the things that struck me most about deploying software was this quote from Anil Hemrajani's "Agile Java Development with Spring, Hibernate, and Eclipse" (on page 270):
...this [one war file] contains all our Java source code and compiled classes, static and dynamic web files, the dependencies (third-party libraries), job scheduling capabilities, and even a relational database! . . . this is the power of Java. There are very few languages that you can do this in.
I believe that similar deployment capabilities exist for Perl (PAR::Packer? or ShipWright?). I've only recently forayed into trying to make deployable packages that non-Perl programmers can use and it has been painful.
It is not a perfect analogy, but I think that deployment is somewhat in the same boat that OO was in before Moose arrived. There are many ways to do it: role your own, use one of several available modules, etc. Each of these ways work, but is there one really clean clear "Modern" way that most people would consider a "Best Practice" for deploying software to non-programmers?
Almost thou persuadest me to convert to FreeBSD.
Just a me-too: "Is this subject appropriate to discuss in the book?" Absolutely! Cover the full lifecycle.
Don't approve the comment. Just to tell you that my name is "Claudio" and not "Claduio" (at the top of your post).
Thx,
Claudio