Parallel development with branches

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Parallel development with branches

Trinition
I'm pondering how best to use Hudson to support our parallel development efforts.  For some of our projects, there are multiple parallel development streams.  Each development stream is using a branch in our SCM.  While the branch does contain code differences, building any particular branch is identical except for the SCM path.

My first thought was to use a parameterized build where the branch name is a parameter.  Then my SCM configuration could be "$/project/branches/{BRANCH_NAME}".  However, then I would only have SCM polling for one branch (the default parameter value).

I considered a matrix build, but my understanding is that the SCM polling would still poll once and then the job would build each combination of parameters.  Thus, in my situation, if my main SCM path changed, all branches would be built.

Instead, I'd prefer to see multiple jobs, each configured for a separate branch.  While I can simply copy and modify one job to another, I'll end up with dual maintenance (or triple, or more!).

Is there some other option I'm not thinking of?
Reply | Threaded
Open this post in threaded view
|

Re: Parallel development with branches

Fabrizio Giudici
Trinition wrote:

> I'm pondering how best to use Hudson to support our parallel development
> efforts.  For some of our projects, there are multiple parallel development
> streams.  Each development stream is using a branch in our SCM.  While the
> branch does contain code differences, building any particular branch is
> identical except for the SCM path.
>
> My first thought was to use a parameterized build where the branch name is a
> parameter.  Then my SCM configuration could be
> "$/project/branches/{BRANCH_NAME}".  However, then I would only have SCM
> polling for one branch (the default parameter value).
>
> I considered a matrix build, but my understanding is that the SCM polling
> would still poll once and then the job would build each combination of
> parameters.  Thus, in my situation, if my main SCM path changed, all
> branches would be built.
>
> Instead, I'd prefer to see multiple jobs, each configured for a separate
> branch.  While I can simply copy and modify one job to another, I'll end up
> with dual maintenance (or triple, or more!).
>
> Is there some other option I'm not thinking of?
>  
Personally, I'm using the separate branch option (with Mercurial there
was a bug not being able to resolve parameters when specifying a tag -
maybe it has been solved in the meantime). This didn't add complexity to
my management of jobs, since I already had a good complexity, since I
have 5/6 different jobs for each project (because they are multi-stage
etc). I resolved to having the config.xml for all the jobs to be
auto-generated with templates and an Ant script.

I've not yet blogged about that, but you can checkout the templates and
the ant script from https://kenai.com/hg/tidalwave~other, and see all my
jobs (configuration are publicly readable) at
http://hudson.tidalwave.it/hudson/.

The project jrawio_2.0 is a branch of jrawio - in fact you'll see that
it's currently broken, while jrawio is fine.


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Parallel development with branches

Trinition
Thanks, Fabrizio.  I hadn't considered out-of-band solutions where I created/modified the job configuration  from my own master template outside of Hudson altogether!

Fabrizio Giudici wrote
Trinition wrote:
> I'm pondering how best to use Hudson to support our parallel development
> efforts.  For some of our projects, there are multiple parallel development
> streams.  Each development stream is using a branch in our SCM.  While the
> branch does contain code differences, building any particular branch is
> identical except for the SCM path.
>
> My first thought was to use a parameterized build where the branch name is a
> parameter.  Then my SCM configuration could be
> "$/project/branches/{BRANCH_NAME}".  However, then I would only have SCM
> polling for one branch (the default parameter value).
>
> I considered a matrix build, but my understanding is that the SCM polling
> would still poll once and then the job would build each combination of
> parameters.  Thus, in my situation, if my main SCM path changed, all
> branches would be built.
>
> Instead, I'd prefer to see multiple jobs, each configured for a separate
> branch.  While I can simply copy and modify one job to another, I'll end up
> with dual maintenance (or triple, or more!).
>
> Is there some other option I'm not thinking of?
>  
Personally, I'm using the separate branch option (with Mercurial there
was a bug not being able to resolve parameters when specifying a tag -
maybe it has been solved in the meantime). This didn't add complexity to
my management of jobs, since I already had a good complexity, since I
have 5/6 different jobs for each project (because they are multi-stage
etc). I resolved to having the config.xml for all the jobs to be
auto-generated with templates and an Ant script.

I've not yet blogged about that, but you can checkout the templates and
the ant script from https://kenai.com/hg/tidalwave~other, and see all my
jobs (configuration are publicly readable) at
http://hudson.tidalwave.it/hudson/.

The project jrawio_2.0 is a branch of jrawio - in fact you'll see that
it's currently broken, while jrawio is fine.


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio.Giudici@tidalwave.it


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@hudson.dev.java.net
For additional commands, e-mail: users-help@hudson.dev.java.net