Is there any method to restrict delivery by CS owner?
Large, monolithic PHP-based application with -lots- of parallel development.
Worst-case application takes 20-25 minutes to unload/load a workspace.
Couple dozen developers working on small standalone projects.
There is a requirement for sanity testing against everyone else's WIP in a single TEST and QA environment
prior to a clean, ready-for-PROD SIT environment.
My BugFix -- BF1, locally validated, ready for TEST
TEST -- contains CS1, CS2, CS3
UAT -- contain CS1 only
I flow changes from TEST, so I have BF1+CS1,CS2,CS3 and test locally
I deliver BF1 to TEST
I now want to flow BF1 to UAT, but want to be careful not to deliver CS2, CS3
The practice we're trying is to suspend CS2,CS3 then flow to UAT.
Technically this works, but seems fragile. Is there a way we can prevent the not-ready change sets from being to UAT prematurely? Looking for something like Restrict Change Set Delivery by CS-Owner option.
I image Required Approval (even self-signed) would work, but they haven't grown into Work Item yet. Other ideas?
Accepted answer
How do you tell a change set is not ready if you don't have some kind of information on it e.g. like a work item?
You could prevent the users to deliver to UAT at all and delegate it to a different user. However, you have to give him the information and the easiest way to do that is a work item with the change set linked to it.
You could prevent the users to deliver to UAT at all and delegate it to a different user. However, you have to give him the information and the easiest way to do that is a work item with the change set linked to it.
Comments
Prevent delivery would be based on roles and permissions and the UAT stream being owned by a specific team, where they don't have deliver permission.
You can also create custom adviseors to prevent delivery, but you need some information for that, like a work item probably.
In 5.0.2 if metadata on change sets that is not versioned becomes available, you could use such a property, maybe.
Ralph - thanks for the comments.
The current process is that each developer owns the lifecycle of their changes through at least UAT. Sounds like it might be worth while to introduce work items early than we might have. A little better transparency on what is probably 15 active little projects will certainly add value as well.
I think it would provide you with a lot of benefits.
As a side note, I create articles for this site. But I have no rights to deliver to the stream. After approval another user with that rights grab my change sets from the work item and accepts them into their repository workspace to deliver them.