Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

reducing the number of build definitions, help!

 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. 

0 votes



2 answers

Permanent link

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.

1 vote

Comments

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

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. 

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

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.


Permanent link
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....

1 vote

Comments

I have not.. thanks for the pointer.. 

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 562

Question asked: Mar 17 '14, 11:08 a.m.

Question was seen: 5,613 times

Last updated: Mar 18 '14, 10:51 a.m.

Confirmation Cancel Confirm