Cruisecontrolrb users - Feb 2008 - Best way to handle release branches?

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.

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

On Feb 2, 2008 1:01 PM, Will Sargent <will.sargent at gmail.com>
wrote:
> 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?
If you create a separate project with the branch URL, and give it an
appropriate name (different than the trunk project), this should work
fine.  The only problems we''ve had is when some of our deploy task
tests did a switch on the working copy - but if you don''t do that, it
should stay pointed to whatever branch URL you originally created
with.

So, bottom line, a separate project per branch.  Reply to this thread
if that doesn''t work...

-- Chad