in reply to Re^2: deploying Perl project to production
in thread deploying Perl project to production
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.
|
|---|