|No such thing as a small change|
deploying Perl project to productionby megamic (Sexton)
|on Aug 14, 2008 at 23:54 UTC||Need Help??|
megamic has asked for the
wisdom of the Perl Monks concerning the following question:
So my team has a project in development (several in fact), each managed under SVN and nicely stored in their own directory tree. Eg.
./project1/bin ./project1/lib ./project1/docs ./project1/etc ./project1/var
The question comes to deploying all these projects to a production environment. Does it make sense to keep each project in its own little path, or invert the structure thus:
/data/bin/project1 /data/bin/project2 /data/lib/project1 /data/lib/project2
(I should point out we have no ability to install under the 'proper' paths like /var /etc /usr ...).
The first approach makes deployment a cinch (svn export...), but makes it hard for other scripts want to use modules from that project, as they need to have it in their path (ie update PERL5LIB every time a new project is installed).
The second approach makes it easy to find all the libs and bins installed from all projects, at the expense of difficulty in say installing or removing all components of a project.
What I'm really after is just general advice and wisdom on effective approaches to deploying multiple Perl projects into production, that makes it easy to reference the installed modules as-well as managing the installation of individual projects.
parsing XML is easy, said the data modeler to the programmer...you just look for an angle bracket and...