Why are we receiving Gap Editor issues when we try to deliver to a Release Stream from a Team Stream?
We are running 4.0.5 and have created a Team Stream for Developers to do their work. Once the work is code reviewed and approved they merge to the Release Stream. The Release Stream is used for building QA/Release Candidates only and no development occurs on this stream. We are finding that when a developer tries to deliver their changes to the Release Stream Workspace the Gap Editor marks a number of discrepancies that do no seem correct. The developer is getting flagged for missing files and directories. The question here is that the workspace was created from this Release Stream and no code changes by this developer have occurred? Are we doing something wrong? Is this how the gap editor should work? Our developers are getting very frustrated as we put this model in place as a basic copy merge scenario and do not believe we should be seeing GAPS?
Any advise
showing 5 of 9
show 4 more comments
|
One answer
|
https://jazz.net/library/article/649 is the best solution I have come across. Post activities for delivery with successful build seems most practical.
|
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.
Comments
Please provide more detail on exactly what steps are performed that lead up to the gap conflict being reported. In particular, when you say "the workspace was created from this Release Stream and no code changes by this developer have occurred", what was added to this workspace? (If nothing had been checked in or accepted into this workspace, there wouldn't have been anything to deliver).
Hi
the developer creates a work space off the Release Stream. Accesses the work items link tab and accepts the change sets that have been delivered to the Team Stream. He will then deliver to the release stream for a QA/Prod build. When this task is performed the developer gets the GAP and it indicates missing folders and files? The Release Stream and Team Stream were generated from the same baseline in the component?
Does the developer get the gap when he tries to accept the change sets into the workspace, or when he tries to deliver the change sets from the workspace to the Release stream?
Geoffrey if possible it would be great to show you the situation. Here is the best I can describe.
Team Stream -- all developers do changes, deliver, accept changes into their team stream workspaces no problem.
Release Stream - developers or touching the same file some instances. What happens is that developer a doesn't deliver his changes to the release stream which is the initial change of foo.c in the team stream.
Developer b comes along and his release stream workspace looks good no incoming because Developer A didn't deliver yet. So now Developer B tries to deliver. Gap shows up and the trouble begins. Because Release Stream is not in sequence with Team Stream. Doesn't know about Developer A changes. Developer B saw the changes in the Team Stream and incorporated them into his change but now he can't deliver to Release Stream because Developer A did not.
Confusing right?
really not confusing at all.
Sam
So what you are saying here is there needs to be a Release Workspace that is shared by all team members. The changes should be accepted into this workspace from the work item changeset on the links tab and delivered from the shared workspace. Rather than developers managing their own separate Release Stream workspaces that they load and accept changes into to deliver. Or we do a deliver and resolve work items with the auto promotion from the Team stream to the Release Stream with a successful build on Team Stream.
developers should never deliver directly to the release stream. and should not have access to a release workspace.
if u want selectivity of content in the release stream, then u need to accept Team stream changes to a workspace, build, and then promote (deliver) those changes to the release stream. then there is a release stream workspace for building the accepted changes into the release stream.
consider build user another team stream user. sharing what the developers deliver.
only build user delivers to release stream.
this is how u prevent the problems u are experiencing.
thanks for the info. I think we are going to follow the advise outlined in this article
https://jazz.net/library/article/649
I will search for something more current. We had proposed the post delivery to the team and they were not keen on the idea. Introduction of the recent events that have impacted the merge and the challenges they present has now validated our original design. If anyone knows of other articles of value please advise. I find 649 to be quite useful
thanks again
yes, a good article.
we are planning on 3 stream approach..
multiple teams (working on unique components of the final app)
each with their own stream
and integration stream, where all that comes together
and a release stream
there have been discussions of a QA stream between integration and release.
developers shouldn't care, unless they have been slipstreaming undocumented changes into the system (by delivering direct to release).
everyone else should want the extra isolation protection.