Same build definitions for different target streams
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
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.
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.