[Catalyst] Development environments and performance

[Ian Docherty]

I agree mostly with what everyone is saying about development machines, 
staging (others here call them test) and live servers and we do that for 
our other products but our Catalyst app is still under development and 
so we don't have staging or live (yet).

I would make further points (see below)

Dave Rolsky wrote:
> 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.
Our team is small and I am the administrator so I don't want to add to 
my burden ;)
>
> 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.
I actually have my own development box as you suggest and it works fine 
but our start-up company cannot afford hardware for every developer. We 
have a managed server which replicates mostly the final live 
environment. (can you replicate something that does not exist yet?)
>
> * staging is as similar to production as possible, and staging _exists_
Agree totally.
>
> * 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.
Not thought of this before in this context but it makes sense.
>
> Shared dev machines made sense about 10 years ago, but any place still 
> using them is hopelessly backwards (err, like my current employer ;)
Backward or skinflints?
>
>
> -dave
>