On Wed, 16 Jan 2008, John Goulah wrote:
Also, one box per dev is a fine solution, if you ensure everyone is using
the same modules. But I've seen it happen where some developer is using a
different module version than prod and that can cause much greater issues.
Either way I'd recommend maintaining a Makefile.PL + local::lib to resolve
this. If you build the prod modules from the same Makefile this problem
typically goes away.
Clearly, there are additional administrivia issues to deal with when you
have one box per dev. You mentioned a couple ways to solve this, and
another might be to use packages of some sort.
OTOH, being able to run different versions of modules is also an advantage
since it lets one dev test out some new modules or new versions of old
modules without affecting everyone else, along with testing database
changes, server config changes, etc.
I'm quite convinced that the only sane environment for getting shit done
is:
* dev is one box per dev, with the best hardware affordable - nowadays
that means at least a dual core machine with 4GB of ram and decent disks.
* staging is as similar to production as possible, and staging _exists_
* even better is the ability to make hot copies of the production
environment into VMs for the purposes of testing major upgrades (database
changes, new daemons, etc). The reason to use a VM is to make the process
repeatable.
Shared dev machines made sense about 10 years ago, but any place still
using them is hopelessly backwards (err, like my current employer ;)
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
