It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×11,924
×562
×11

question asked: Mar 17 '14, 11:08 a.m.
question was seen: 5,054 times
last updated: Mar 18 '14, 10:51 a.m.

Related questions

FAQ - How this Forum works

reducing the number of build definitions, help!

0
sam detweiler (12.5k●6●195●201) | asked Mar 17 '14, 11:08 a.m.
edited Mar 17 '14, 1:52 p.m. by Millard Ellingsworth (2.5k●1●24●31)
 we have a couple teams that have 20 or more unique products that ship an maintain completely separately. We've migrated them from SVN projects wih trunks/branches to RTC SCM, using streams and workspaces
(stream for the trunk, stream for developer integration and stream for release, with workspaces in between as required. 

now we want to setup a set of build definitions  to handle all this..so we need 1 for the integration stream workspace,
maybe one for the release stream workspace, 1 for the maint stream workspace, 1 for personal builds 
and now we have 80 to 100 build definitions.. they are mostly identical, except that the workspace selected is different. 

is there someway to reduce this some? 

we can't combine components into a single stream as the release, delivery and support cadence for each component is different. (and totally independent).

the developers will have a unique workspace per component as well. 

2 answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Victor Campbell (350●26●18) | answered Mar 17 '14, 3:10 p.m.
edited Mar 17 '14, 3:11 p.m.

I can answer the issue about multiple release builds.  Here's what we've done:

We've created a unique project area for release builds.

  • Included in the release build project area are all components from multiple project areas.  We set the appropriate baseline on the component we are building.
  • We created a single "command line" build.  The .cmd file contains the unique build options defined for each build.  Our command file contains options for 30 builds.
  • When requesting a build, we select the "Build Properties" options, manually setting which build we are performing.

The downfall is that the build workspace is populated with a whole bunch of stuff we don't need for the each build, but doesn't seem to take a minute or two longer to load than if we only loaded specific components.

Comments
sam detweiler commented Mar 17 '14, 8:28 p.m.

hm.. that puts a lot of implementation into the script which will be hard to maintain.  I am hoping we can do something different.

Victor Campbell commented Mar 18 '14, 10:40 a.m.

No Sam, not really.  Our batch script contains exactly one line, kicking off a maven command line build using "mvn".  All of the properties come from the build definition or parameters in the pom file, and the manual input we provide when requesting a build is the path to the pom file.  Worked the same when we were using ant, the variable being the path to the ant file.  Nothing to modify in the script when adding additional builds. 

sam detweiler commented Mar 18 '14, 10:43 a.m.

how do you specify the workspace to source from  and the components to include/exclude?

Victor Campbell commented Mar 18 '14, 10:50 a.m. | edited Mar 18 '14, 10:51 a.m.

We use a generic workspace and load everything for every build.  Every build loads more than is used, in our case 10 components, but any individual build doesn't look at the other 9, or any other build that is included in the component it is using.
1
permanent link
Davyd Norris (202●2●10●14) | answered Mar 17 '14, 6:42 p.m.
Hey Sam,

You may not be able to reduce the number of build definitions, but you can now organise them a lot better in 4.0.6 with the new folders they have added to that area. Have you seen that feature?

https://jazz.net/downloads/rational-team-concert/releases/4.0.6?p=news#build_definition_folders

I've found that little gem awesome for making things easier to see and organise. The hard part is working out the best format - do you put the DEV/QA/REL definitions under a product folder, or do you put all products REL definitions under a REL folder? Would love to hear other's thoughts....
Comments
sam detweiler commented Mar 17 '14, 8:27 p.m.

I have not.. thanks for the pointer.. 

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.