[Catalyst] OT: managing multiple environments

Matt S Trout dbix-class at trout.me.uk
Tue Jun 13 14:06:28 CEST 2006


A. Pagaltzis wrote:
> * Allen S. Rout <asr at ufl.edu> [2006-06-12 21:20]:
>>>> On Mon, 12 Jun 2006 02:00:15 +0200, "A. Pagaltzis" <pagaltzis at gmx.de> said:
>>> Just note that the more environments there are, the more
>>> porting from one to the other you'll be doing. The friction
>>> is just about bearable with 3 environments. Beyond that, you
>>> waste significant amounts of effort on managing the setup.
>> I'd suggest that it ought to be technically effortless to
>> transfer an app from region A to region B.  Yeah, you need to
>> write some code to do it, but the -operational- complexity
>> shouldn't scale with the number of regions.  How much effort
>> does it take to deploy a new copy of a properly built WAR or
>> EAR?  
>>
>> Knowing your app well enough to do this is also useful when you
>> want to be sure you've backed it up.
> 
> I agree with all that; but it’s only true in the forward
> direction (devel --> test --> prod). Unfortunately, you’ll often
> also have to port changes the other direction between devel and
> test. After all, that’s a major reason to have a test environment
> in the first place: so you can test specific fixes for problems
> found in the production code, and then push them out.
> 
> In version control parlance, test+production run a branch of a
> known-good snapshot, and the devel env runs the trunk. What I’m
> saying is that you will be porting changes between that branch
> and the trunk, which can’t be automated, but eats up effort.
> 
> As you add more environments, you get more snapshot branches, and
> correspondingly more change-porting friction.

This is why I never do stuff that way. trunk is bugfixes only and we maintain 
a branches/CURRENT branch for integration of new development work and "real" 
branches. That way trunk is guaranteed stable for bugfix releases and we hit 
svk push on CURRENT for a feature release.

I originally developed this approach for DBIx::Class development but we've 
since adopted it for all production projects as well. Works extremely nicely.

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +



More information about the Catalyst mailing list