It's all about the answers!

Ask a question

Same build definitions for different target streams


Carlos S (471713) | asked Feb 12 '14, 9:42 a.m.
retagged Feb 14 '14, 11:44 a.m. by Dejan Custic (2855)
 Hi,

we have a stream for current development (Stream Development), with some components and build definitions associated with those components:

Stream Development (version 1.0 released, current working on version 2.0)
 Comp_1 (LATEST)
 Comp_2 (LATEST)
 Comp_3 (LATEST)
 Comp_4 (LATEST)
 Comp_5 (LATEST)

 build.def_comp1 (build.def_comp1.workspace - flow target "Stream Development", scoped to "Comp_1")
 build.def_comp2 (build.def_comp2.workspace - flow target "Stream Development", scoped to "Comp_2")
 build.def_comp3 (build.def_comp3.workspace - flow target "Stream Development", scoped to "Comp_3")
 build.def_comp4 (build.def_comp4.workspace - flow target "Stream Development", scoped to "Comp_4")
 build.def_comp5 (build.def_comp5.workspace - flow target "Stream Development", scoped to "Comp_5")

Maintenance on version 1.0 is now necessary, so we created "Stream Maintenance 1.0" from Snapshot "1.0":

Stream Maintenance 1.0 
 Comp_1 (1.0)
 Comp_2 (1.0)
 Comp_3 (1.0)
 Comp_4 (1.0)
 Comp_5 (1.0)

I'm in doubt if I should create a new build definition (and a new build workspace) for each component again, but now having the flow target to "Stream Maintenance 1.0": 

 build.def.maint.1.0_comp1 (build.def.maint.1.0_comp1.workspace - flow target "Stream Maintenance 1.0", scoped to "Comp_1")
 build.def.maint.1.0_comp2 (build.def.maint.1.0_comp2.workspace - flow target "Stream Maintenance 1.0", scoped to "Comp_2")
 build.def.maint.1.0_comp3 (build.def.maint.1.0_comp3.workspace - flow target "Stream Maintenance 1.0", scoped to "Comp_3")
 build.def.maint.1.0_comp4 (build.def.maint.1.0_comp4.workspace - flow target "Stream Maintenance 1.0", scoped to "Comp_4")
 build.def.maint.1.0_comp5 (build.def.maint.1.0_comp5.workspace - flow target "Stream Maintenance 1.0", scoped to "Comp_5")

My concern is that in this way I will have to duplicate* all my build definitions and build workspaces for each parallel development needed (maintenance, emergency bug fixes, or new feature/release streams, for example). 
    * at least for each component that need maintenance, fix, etc

Or should I use the same build definitions already created, only changing the flow target of their workspaces from "Stream Development" to "Stream Maintenance 1.0" when an official build of maintenance be necessary?

I know that its a best practice to have a dedicated build workspace for each build definition, but I´m not sure if changing the target stream every time I need to build a different parallel configuration of the software would be the right approach to take. I think this could mess the build result history (work items included, changes, etc).

I believe that creating new build definitions for each parallel development effort would be more appropriate, but my concern is that the number of build definitions and build workspaces would increase very quickly. 

Certainly this is a basic question, but I just want to be sure that having many build definitions/workspaces "duplicated" (only with different target streams) is normal and the correct approach to follow when having parallel development streams with their own releases.

Thanks for any advice!

Carlos

Accepted answer


permanent link
Lily Wang (4.9k714) | answered Feb 16 '14, 8:21 p.m.
Hi Carlos,
As I known, there's no limitation about how many build definitions or workspaces can be created in a RTC repository.
So I think you should follow the best practice to create new build definitions and dedicated build workspaces for new streams.
To save the time, when you create new build definitions, you can use "Create a build by copying an existing build definition".
In addition, to avoid the database grows too fast, you can enable prune build result task to delete the build result regularly.
Carlos S selected this answer as the correct answer

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.