[Cruisecontrolrb-users] Best way to handle release branches?

[Brian Ketelsen]

I'm all ears for answers on this one too.  We have trunk for local  
development, "integration" for the first integrated environment (still  
owned by developers), "qa" for the branch in testing at any given  
time, "UAT" for the branch that's passed QA and is going to production  
when accepted by the business users and "production" which is the  
currently released branch.  It's painful.  And so is merging in SVN.   
But I suppose that's off topic.

Brian


On Feb 2, 2008, at 3:01 PM, Will Sargent wrote:

> Hi all,
>
> This is a question I've had with CruiseControl in general, but as I'm
> going over it now I thought I'd throw it out there.
>
> When I was using CruiseControl in Java, I managed release branches by
> aliasing:  I'd have three projects for each product:
>
>  dev       -- mapped to the trunk (mainline development)
>  staging -- mapped to the release branch about to be released
> (Mostly QA checks out from this branch, dev merges fixes in)
>  prod     -- mapped to the release branch that has already been
> released.  (Used for patches, mostly)
>
> This was a nice way to handle the multitudes of releases that we did,
> because we cut release branches fairly often, and it gives visibility
> to QA and management about what's been checked in.
>
> My question is: does cc.rb have any way to manage this internally?  Or
> is the best way to handle this by using svn switch on the backend?
>
> Also, I'm curious to hear how other people structure their
> cruisecontrol around their release engineering process.  What's the
> normal convention for agile projects?
>
> Will.
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users