deploying Perl project to production

[megamic]

Ok..

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.

Cheers

[Fletch]

Stage each project to a separate top-level directory named after the release tag (you're of course tagging your revisions; or at best name it after the revision it corresponds to). Use svn export if you're really paranoid to completely break any ties back into a repository from live code. Symlink the "real" path to that project back to the current version. That way you can easily switch between versions by repointing symlinks, plus with judicious environment twiddling (see Envy from CPAN; it's a bit long in the tooth but works fairly well once you get it configured to your liking) you can point to a specific release if need be while not affecting the "default" version.

[megamic]

Thanks for the advice.

In regards to SVN, yes we do use tags, however we do 'svn export' from the trunk to the live path when we are satisfied with the changes. Do you suggest leaving the live folders as an SVN working copy of the trunk, and then merging the revisions into it?

Cheers

[Fletch]

No, in an ideal world and if you can live with it doing an export is probably a cleaner mechanism.

Having the released code be a dead copy (in the sense that the directory is detached from your SCM) precludes someone going, "Oh, I'll just patch this one thing" and then committing it back and oops, they didn't tag it and by the way forgot to mention anything to anybody else (and then trouble crops up when someone fixes the same thing in development a different way and they get merge conflicts; or worse the change gets lost and doesn't make it into the next version and the cycle repeats itself). If you've set things up well enough it'll hopefully be easier to go through your release process and things will get tracked correctly ("Oops, I need to add this. Carp, this is a dead tarball export. OK, back to my working copy.").

You want the released version to be a static, unchanging thing. If something happens you have no qualms about clobbering it and regenerating it from another export of the same tag (or untaring your release archive again). Nothing should change in that directory save whatever build products are generated (if you've got XS components for example, or maybe manpages generated from pod), and those can also be destroyed without worrying because they can be rebuilt at will from the static source.

Again, in an ideal world . . . :)

[jbert]

One nice way to do it is to make a distributable perl module out of each project, and do the

export PREFIX=/your/prefix
make
make test
make install

Or even create packages (.deb, .rpm) which matches your deployment platform. i.e. use a well-understood format (perl/CPAN foo.tar.gz or package) as the deployment medium, since you know it works and there are probably additional tools to help you manage. You can normally set up your own package server (local apt source or local CPAN) too.

It's more work to set up initially, but it's nice to use the 'standard' tools for this sort of thing. There are fewer surprises and you get more fringe benefits.

[talexb]

Count this as another vote for the 'install in a directory with the name of the version, and sym-link to that' -- I used that practice at $work[-2] and it worked very smoothly.

And at $work[-1], we use DEBIAN's dpkg to smoosh everything up into a neat little package -- works great.

[alexm]

we use DEBIAN's dpkg to smoosh everything up into a neat little package

I use dh-make-perl to produce .deb packages and it makes things quite smooth if your Perl project is in CPAN or follows common Perl practices. As a matter of fact, I recently used dh-make-perl to make the Padre Perl IDE packages for Ubuntu Hardy, including a few other dependencies.