It's all about the answers!

Ask a question

How to debug and test with other member before deliver code to stream

Sherry Qi (62) | asked Jan 22 '17, 9:12 p.m.
edited Jan 22 '17, 9:12 p.m.

Hi all,

Currently, we set the precondition that code need to be reviewed and approved before deliver to stream.

But we found a problem that when a feature is contributed by more than 2 members, team cannot debug and test together before submit for review. It means all the related members need to submit for review of untested code first, and after approved and delivered, they will debug and test the combined code. If any issue is found, they need to modify the code and submit for review again, which is very inefficient. 

Is there any way to solve this problem? 

Does RTC support to set delivery precondition on specific stream? 
Can public repository workspace be owned by a team? 


2 answers

permanent link
Geoffrey Clemm (30.1k33035) | answered Jan 22 '17, 11:31 p.m.

Yes, you can set the deliver precondition on a specific stream, by creating a separate team area to own that stream.
Or you can have one team member accept the completed changes of another team member directly from that other team members workspace, do the testing/debugging of the combined code, and then deliver the result.
If you want the functionality of a "public repository workspace", you would use a stream.

Sherry Qi commented Jan 23 '17, 1:41 a.m.

 Hi Geoffrey,

Thanks for you reply!

1.In our company, team area can only be the project team, and I also think creating a separate team area to own a stream is not a good idea. Because in this case we need to create at least 2 team areas for each project with the same team members...

In addition, if only 2 team members need to debug and test with each other's code, it is ok to change the flow target and deliver their change set to each other's  repository workspace. But if it is related to 3 or more members. It will also be very inefficient to deliver their code to each others' repository workspace. 

Please let me know your thoughts. Thanks.

Geoffrey Clemm commented Jan 23 '17, 1:54 a.m.

Team areas are cheap, so I wouldn't avoid creating new ones.   To avoid the hassle of managing all the team members, just make the sharing team area a child of the primary team area for that project.   Also, we can see if anyone else on the forum has a better idea (:-).

permanent link
Ralph Schoon (63.2k33646) | answered Jan 23 '17, 3:30 a.m.

I agree with Geoff. The best approach would be to have a feature stream that is used for integration. You could use a repository workspace for integration. The developers can accept completed change sets from work items to get the changes of the other developers, but I find that clumbsy.

It would be possible to create custom preconditions that check for a specific stream and then call the builtin preconditions. I think it is way cheaper and easier to use Geoff's approach.

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.