Testing CPAN modules

tony.x.edwardson at jpmorgan.com tony.x.edwardson at jpmorgan.com
Mon Oct 8 03:09:46 PDT 2007


Hi Tom

I don't think I worded me query very well - I'm deploying 400 CPAN modules 
to 4 Production boxes , not to 400 Production boxes.
With regards packaging, the OS is AIX 5.2 for which there are no Perl 
module packages at present.
However, packaging doesn't actually solve my problem because I have to 
find some way to prove that the modules work when on the production 
machines, the fact that they all pass their test harnesses on development 
is not sufficient for the release to be approved.

In answer to your question, "How do we deploy software to these servers" - 
there is no fixed procedure - if a package is available, we use that,  (I 
gather that on AIX this is not an easy process).
In this case, I am building perl on one of our development boxes using gcc 
and then creating a tarball which I am checking into source control.
This is then put live via the release mechanism here which only allows you 
to put code live from the source control system - I have no direct access.
The problem is, this system requires some form of testing to be done on 
the released code before it can be signed off and I am trying to find a 
way to do this using the test harnesses provided with each module given 
the constraints of the absence of any development tools.

Cheers
Tony 



Tom Hukins <tom at eborcom.com> 
Sent by: miltonkeynes-pm-bounces+tony.x.edwardson=jpmorgan.com at pm.org
06/10/2007 19:04

To
Milton Keynes Perl Mongers <miltonkeynes-pm at pm.org>
cc

Subject
Re: Testing CPAN modules






On Fri, Sep 28, 2007 at 02:47:08PM +0100, tony.x.edwardson at jpmorgan.com 
wrote:
> Anyone knbow of a way to run the test suites which come with CPAN 
modules 
> without access to the internet, make or a c compiler ?
> I am trying to get a recent version of perl (5.8.8) installed on 
> production machines which exist in a highly restricted environment.

Rephrasing your query, you have two issues to deal with:
1. Your production servers don't include compilers or other build
tools.  They're production servers, so they should do their intended
jobs, not compile software or run its tests.
2. You don't want to deploy software in production without checking it
seems to work.

> The problem is that the procedures require me to run tests on all of the 

> modules I've introduced on the production box where make and gcc don't 
> exist.

You mention that you have 400 production servers, so presumably you
have some automated way to deploy them.  Can you deploy the production
environment and then install the build tools you need on top of this
environment?  This will let you build and test your code in an
environment that only differs marginally from production.

> Ideally, I'd like to use the test suites that come with each module but 
I 
> can't use "make test" without make.
> There is "prove" , but not all of the module distributions have a "t" 
> subdirectory - they have a test.pl script instead.

As a heuristic, you could "prove t/*.t test.pl" but this won't work
for modules that have non-standard test procedures defined in their
Makefile.PL, Build.PL or whatever Module::Install uses.  Ziya already
mentioned this in more detail.

> I've played with the CPAN module but I can't find a way to use it 
without 
> access to make.

How do you deploy other software to these servers?  Do you use a
packaging system?  Could you build packages of the Perl modules you
need?  Again, Ziya mentioned this.

Testing your code, compiling it or building packages of it on
production servers strikes me as a bad idea:  these servers exist to
serve, not to build.  But building packages in a very similar
environment that you can then deploy onto production seems both doable
and sensible.

Tom
_______________________________________________
MiltonKeynes-pm mailing list
MiltonKeynes-pm at pm.org
http://mail.pm.org/mailman/listinfo/miltonkeynes-pm



-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates. This transmission may contain information that is
privileged, confidential, legally privileged, and/or exempt from
disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including
any reliance thereon) is STRICTLY PROHIBITED. Although this
transmission and any attachments are believed to be free of any
virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is
accepted by JPMorgan Chase & Co., its subsidiaries and affiliates,
as applicable, for any loss or damage arising in any way from its
use. If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you. 
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/miltonkeynes-pm/attachments/20071008/9cccd859/attachment.html 


More information about the MiltonKeynes-pm mailing list