Thanks again.
--Chung
Hi,
Answers inline...
Although they might be classed more as opinion than answers.
On 27/03/2012 15:59, Ley, Chung wrote:
Hi,
I am very new to Hudson and as a matter of
fact I am new to using CI.
I am looking into setting up Hudson, but
have a couple of general design questions.
I have
projects where each project encompass a number of different
components/parts where each part is being developed by a
different set of developers. What is the best way to model
that in Hudson?
We use Hudson project jobs
for each component in this case, then each dev team can see
there component build and test results by checking there job
results. You cna then use artifacts from those component
jobs to build larger integration projects that show results
of that integration, building up to the logical 'whole
thing'. It's slightly harder to architect, although not that
hard if you are using maven.
The
"test" job/script that need to be done for some of these
components can be huge tasks and the job need to submit to a
virtual farm for "execution". Is that possible? How do you
approach that? It sounds like I like to install some
execution agent/broker in the server farm side to make this
happen.
Depending on how you submit
to this farm and how the results are reported you could use
a Hudson job to submit and wait for the results, although
this would block a Hudson executor, it wouldn't massively
increase your server load as it would just be waiting.
Investigate the build timeout plugin to protect from farm
failures etc...
Also have a look at Hudson's ability to fingerprint files in
sub-projects and join up test results based on the shared
usage of a fingerprinted file.
Do you
manage the development + main + release branches all in the
same CI server or do you manage them in separate CI? How do
you model it such that the main is "build" from the
development? How do you make such build that by default it is
only on a successful build (without error) from the
development, but allow certain users to override it?
You can manage these in the
same CI and promote builds up through the levels. Have a
look at the promoted builds plugin for what you can do. You
can streamline the UI by having development, main, and
release views that can be used by the different groups, dev,
qa, etc...
Thanks…
--Chung
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hudson-dev
