Re: deploying Perl project to production

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.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re: deploying Perl project to production

Replies are listed 'Best First'.
Re^2: deploying Perl project to production by megamic (Sexton) on Aug 15, 2008 at 05:54 UTC
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 parsing XML is easy, said the data modeler to the programmer...you just look for an angle bracket and...	[reply]
Re^3: deploying Perl project to production by Fletch (Bishop) on Aug 15, 2008 at 12:40 UTC
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 . . . :) The cake is a lie. The cake is a lie. The cake is a lie.	[reply]