Build automated Perl upgrade workflow

[preaction]

When new versions of Perl are released, we need to be able to easily upgrade. This means that we need a task to install the latest version of Perl, but also that we need to ensure that each individual project can be easily deployed into the new Perl without breaking.

Ideally, this project would have a task to create a new Perl installation in the perlbrew, and each individual project would deploy to the "latest" Perl when it was next deployed.

Some possible problems to ensure are addressed are:

• Compiled modules must be recompiled for the new Perl. This is generally handled by the individual Perl project's deploy task, and handling it there will be fine.
• The new Perl and associated modules must not interfere with the running production environment while they are being prepared. This likely means that an individual project must keep track of what Perl it was deployed with. This goes along with the next bullet point.
• Ideally, an individual project would use the old Perl until it was deployed, at which time it would notice that there is a new Perl and try to deploy that. This probably means that each individual project must be deployed so that their #! line is changed to the correct Perl path so they use the right Perl that they were installed to.
• It should be possible to specify which Perl a project should deploy to in case of incompatibilities or hotfixes or otherwise. This should be done as an option to the deploy task.

[glasswalk3r]

Couldn't we use Docker for each, I mean, one image for each application your their own perl?

[preaction]

We could, but we don't have enough hardware to handle the overhead of the VMs (however slight Docker makes that), we don't always get a choice of what hardware we get and what it can do, and we don't have the staff to maintain the added complexity. Docker is overkill for the problem we're trying to solve (and that I'm not too concerned about solving due to how rare the situation is).