A. Pagaltzis wrote:
> * Allen S. Rout <[EMAIL PROTECTED]> [2006-06-12 21:20]:
>>>> On Mon, 12 Jun 2006 02:00:15 +0200, "A. Pagaltzis" <[EMAIL PROTECTED]>
>>>> 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/ +
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
