It's all about the answers!

Ask a question

Why are we receiving Gap Editor issues when we try to deliver to a Release Stream from a Team Stream?


Wendy Murphy (1512433) | asked Feb 09 '14, 12:59 p.m.
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

Comments
Geoffrey Clemm commented Feb 09 '14, 9:24 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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).


Wendy Murphy commented Feb 10 '14, 6:49 a.m.

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?


Geoffrey Clemm commented Feb 10 '14, 4:07 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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?


Wendy Murphy commented Feb 10 '14, 4:36 p.m.

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?


sam detweiler commented Feb 10 '14, 5:33 p.m.

really not confusing at all. 


developer A delivered to a stream.  all developers connected to that stream will get notified of incoming changes. 

developer B accepts A's incoming changes into his workspace

but NOW developer B tries to deliver a NEW change to a second stream, which also carries developer A's changes. ( which are documented in the change sets B accepted)..

developers should not be delivering to an uplevel stream directly. 
they should have ANOTHER workspace which is the accept of the Release stream.

B pushes his changes to Developer
A & B are now together.. 

someone else pushes team stream changes to release.  (NOT Developer B changes to release directly) this is the role of a 'Release Engineer'




Wendy Murphy commented Feb 10 '14, 8:01 p.m.

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.



sam detweiler commented Feb 10 '14, 8:34 p.m.

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.


Wendy Murphy commented Feb 10 '14, 9:09 p.m.

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


sam detweiler commented Feb 10 '14, 9:15 p.m.

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.

showing 5 of 9 show 4 more comments

One answer



permanent link
Wendy Murphy (1512433) | answered Feb 10 '14, 9:10 p.m.
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


Register or to post your answer.