Re: how to improve: use MODULE VERSION LIST

IMO you are solving the wrong problem :) The problem is you have two environments (for now :-)) and you are storing & deploying them together. This can only end in tears when change X for team Y affects team Z and you have no idea why Team Z's production app suddenly exploded when no one touched it.

Separate the module versions in your repository, paths, branches, however your repo is set-up.
Use jails, chroots, containers, VMs, etc, to isolate the deployments.
Only expose the appropriate repository version to each deployment.

Personally I'd just use your OS's package manager for the modules as it makes isolating deploying & upgrading individual systems easier to orchestrate if the environment starts to scale out ... but I also prefer cider to beer so YMMV ;)

Comment on Re: how to improve: use MODULE VERSION LIST

Replies are listed 'Best First'.

Re^2: how to improve: use MODULE VERSION LIST
by RonW (Parson) on Jan 10, 2017 at 03:20 UTC

Personally I'd just use your OS's package manager for the modules

Are you suggesting the OP rely on the OS's package repository? Or suggesting the OP create packages for deployment using the OS's package manager?

If the first, generally it is a bad idea for "non system" Perl applications to use the "system Perl" as updates are more likely to cause problems. It is better to leave the system Perl for OS's use and install one or more separate versions of Perl for non system applications.

If the second, I think it would be easier (and more portable) to deploy applications by creating the same type of package CPAN uses. The resulting tar.gz file can be copied to each server and the cpan command con be used to install it:

$ cpan
cpan> install myapp.tar.gz
[download]

Would even be possible for the OP to setup a CPAN-like archive and direct cpan to use that before using the actual CPAN archive.

[reply]
[d/l]


The stupid question is the question not asked
	PerlMonks