Matisse Enzer wrote:
Currently we are evaluating these options:
1) Maintain a list of the .tar.gz files and install from CPAN,
for example M/MA/MATISSE/Text-TagTemplate-1.8.tar.gz
2) Put the CPAN .tar.gz files in a local CPAN repository and use
CPAN::Site to install - that way we *only* get the versions in
our local CPAN repository and dependencies are managed by the
module Makefile.PL / Build.PL scripts.
3) Put the .tar.gz files in our source-code control system, and checkout
and build each one during a release process.
4) Build these modules on one machine and check the *built* files into
out version control system (including *.so files - all our machines
are Solaris boxen)
What do other folks think?
None of the above.
At Citigroup I do the following.
1. Import any Perl module that we need in to our Subversion repository.
2. Wrap our build system around it. The build system builds it,
installs it in to a 'fake' install directory, and generates a SysV
package file. Commit the build system files to the repository.
3. Tag the package in the repository.
4. Our operations group use an automated tool that checks the modules
out of the repo, and generates the SysV package. Then they deploy the
package.
Upside:
* The build process is completely repeatable. We're a big financial
institution, so that's incredibly important.
* Each module is its own package, so they install in to a path with a
version number in it somewhere. So you can deploy multiple versions of
the same module (App1 tested with Foo::Bar 1.1, App2 tested with
Foo::Bar 2.0 can run on the same machine).
* The build infrastructure captures, in a concise fashion, any changes
or oddities that had to be made to get the module to build.
Downside:
* You have to chase down dependencies yourself. Installing a module
with 6 dependencies means you've got to package a total of 7 modules.
* paths-with-version-numbers-in-them means you need to add C< use lib >
lines in many modules, introducing (small) local changes.
N
