On Mar 6, 2006, at 4:10 AM, Nik Clayton wrote:
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
It sounds like you are doing a more advanced version of #4 in my
list. I like the way you are using SysV packages - that should speed
up installation, no compiling, etc.
At the moment I think we are going to go with my #2 - create a local
CPAN repository inside our SVN repository, in order to get the
benefit of dependency unraveling. We'll use Module::Build in our
local code, so our developers can assert any dependencies they want
and the build system will take care of installing the modules (if
they are in our "blessed" list, in our local CPAN.)
We also want repeatability, and so each release is a "fake" install
directory, with a unique id - based on the SVN version and the date,
something like:
/home/team-A/versions/release-20060305-3276/
a "release" will include an entire code-base - local and CPAN
modules, everything except Perl, and the core Perl modules installed
in the system directories (/usr/lib/* etc.)
Each release gets installed as a subdirectory of a "versions/"
directory local to the team whose code is being released (multiple
teams share a box) - then there will be a symlink pointing to the
current release. Rolling back to a prior release is a simple matter
of changing the symlink, or at worst, checking out and rebuilding
from a prior SVN version:
/home/team-A/installed -> ./versions/release-20060305-3276/
We'll offer to build modes: "normal" and "from scratch" - in a
"normal" build the build system will copy the last release and use it
when checking dependencies, so if Module::Foo 1.0 was already
installed it won't build it again. The new release gets built "on
top" of the old one - that will leave obsolete files around though,
so a "from scratch" build will start with nothing and build all
modules. This is where storing the installed images in SVN would help
(e.g. SysV packages.)
Downsides:
* If one of our local modules depends on Module::Foo version 1.0
and another depends on Module::Foo version 1.2 AND 1.2 is not
backward compatible then we'll have a problem - in practice this is
very rare, but it is a small concern.
* If we need to make changes to a public module to get it to build we
need to deal with that somehow, probably by putting it in a different
part of our local CPAN - under a different author id perhaps?
-------------------------------------------------------
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/ - http://www.eigenstate.net/
