Team development question

[Former Member]

Scenario is this:

1) Four developers start working on new application ABC on June 1st.

2) Phase 1 of application ABC is put in production on September 15th.

3) Developers begin working on phase 2 coding on September 16th.

4) A production problem is discovered on October 5th. Developer 1 breaks away from phase 2 work and starts making changes to code that went into production on September 15th.

5) Developer 1 implements production problem fixes on October 6th.

6) Code changes made to fix production problem are merged into the phase 2 code.

7) All 4 developers continue coding phase 2 which now includes the production fix code.

We feel this is a pretty realistic situation. However, we’re having a difficult time figuring out how to implement this scenario using the NWDI.

From reading SAP’s documentation it seems that this fits under the Scenario 3 description. Based on that, here’s how we’ve tried implementing it:

1) On June 1st, create a track called ABC1.0. Track contains a web module DC and an Enterprise Application DC. All 4 developers code in the web module, check into the DTR and activate their changes to the development server.

2) On September 15th, release track ABC1.0 is released for transport to the QA and then PROD server. At that time a copy of track ABC1.0 is made. This new track (ABC1.1) will contain the phase 2 changes.

3) All 4 developers code the phase 2 changes in track ABC1.1

4) On October 5th, another copy of track ABC1.0 is made. This one is called ABC1.05. Developer 1 makes changes to this track to fix production problem. A repair connection is setup between ABC1.05 and ABC1.1.

5) On October 6th, track ABC1.05 is released for transport to QA and PROD servers to fix production problem.

6) After production problem is fixed, coding on track ABC1.1 is halted and all changes are checked into DTR. Imported ABC1.05 Software Component into the development queue of the ABC1.1 track.

This is where we are stuck. We expected that there would be some kind of warning/notification that there were code conflicts but there were none when we did the import.

Then we thought that if developers synched their sources they might get some kind of notification that there were conflicts. Didn’t happen.

Then we thought maybe if we made changes to code in track ABC1.1 and tried to check them in we would get conflict notification. Still didn’t happen.

Then we thought maybe if we change the EXACT SAME programs in ABC1.1 as were changed in ABC1.05 we’d get conflict notification when trying to check them in. Still no notification.

So the question is, how do we handle this situation.

Any help would be GREATLY appreciated.

[former_member183805 · Accepted solution]

Hi David,

1) The following article explains in detail how to setup the track landscape to address such scenarios:

/people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases

2) In the process you have described, Track ABC1.05 is redundant (See above article for details)

3) Conflict notification is through the "Integration Conflicts" view in the DTR Perspective - did you check for conflicts in that view?

4) If you have setup a repair connection, why did you additionally import the ABC1.05 SC into ABC1.1 track (See above article for details)

5) For JDI related questions, there is the JDI forum - please place such questions there. We can continue with this thread here, of course. Please get back to me if you have further questions.

Regards,

Manohar

[Former Member · Accepted solution]

Manohar,

Thank you for your reply.

We have in fact read the article you reference and that's what we're basing our scenario on.

Can you elaborate why you think track ABC1.05 is redundant?

Our reasoning for creating it is that we need to have a point-in-time snapshot of what an application looks like. Our understanding is that the only way to do that is to make a copy of the track and give it a new name. Hence track ABC1.05 because it will be a point-in-time snapshot of what the production system looked like after the bug fix was implemented.

To elaborate on our scenario a little more:

Both developer 1 and 2 made changes to the same file (let's call it xyz) in the tracks. Developer 2 made changes to ABC1.1 as part of the enhancement process while Developer 1 made changes to the SAME file in ABC1.05 as part of the production bug fix.

Developer 1 checked in the changes to ABC1.05 and had them transported to production.

Then Developer 2 checked in the changes to ABC1.1 and removed the ABC1.1 configuration from the workspace.

The Admin then imported ABC1.05 into ABC1.1.

Next Developer 2 imported the ABC1.1 configuration to the workspace and opened file xyz. File xyz reflected changes made by Developer 2 in ABC1.1. The changes made by Developer 1 in ABC1.05 were not there.

Developer 2 started making changes to file xyz, saved and checked them in and was NEVER notified of any conflicts.

So bottom line is that the enhancement track (ABC1.1) never got the code changes made to fix a production problem in ABC1.05.

You mention the DTR perspective for identifying conflicts. From what I've seen so far, there is no way to ask the tool to tell you of ALL conflicts in a track/DC. All I've seen is the ability to pick a specific object and check for conflicts on it.

It is unrealistic to expect developers to go through every single program/file individually and ask the tool if there is a conflict.

There must be an easier way.

Thanks again.

David.

[former_member183805 · Accepted solution]

Hi David,

Firstly, about the conflicts. There is a SEPARATE VIEW in the DTR perspective - it is called the INTEGRATION CONFLICT VIEW. It shows all conflicts existing in a workspace (a workspace in DTR maps to one SC), and a developer can set filters on the workspaces he is interested in and also whether he is interested in his own conflicts (where one of the versions involved in the conflict was created by him) or on all conflicts.

So a developer does not have to examine each file in the DC to check if it has a conflict - he only has to look into this special view and see if any conflicts are listed under the SC he is working in. And from the conflict object he can navigate to the version graph, he can view differences between conflicting versions, he can find the activity which brought in the conflicting change, and also initiate a merge.

There is yet another interface for conflict report: the DTR Web UI. You will find it under the following url:

http://<host>:<port>/dtr/system-tools/reports/CollisionQuery

This is a raw view which lists the conflicts and some properties.

About your point concerning getting a notification while editing a file : this is already in place in the DTR Perspective. From this perspective, if you try to Edit (Checkout) a file having an integration conflict, you'll get a popup telling you that a conflict exists. Of course, it would be nice to get such a notification even if upper layers (like the WebDynpro toolset or J2EE toolset) trigger a checkout - but this is not yet in place. Until then, you need to follow a guideline to periodically examine the Integraion Conflict view to see if any files you worked on have conflicts.

Second, about your track landscape. To meet your requirement (described in the scenario at the beginning), I would recommend the following:

- Create a track named ABC (use it for the development of the latest release/phase. So you start with phase 1 here)

- At the end of phase 1, create track called ABC1.0 (representing phase 1) as a copy of track ABC, and foward the assembled version to this track (ABC1.0). Connect your production runtime system to this track. Also create a repair connection from ABC1.0 to ABC.

- Continue developing phase 2 in ABC, and use ABC1.0 as the track where you fix issues arising out of the phase 1 state.

- So when you need to fix your production bug, fix it in the "Dev" system of ABC1.0 (since it represents the state deployed on the production system). When you release this fix (from the Transport View of the IDE), it will automatically get transported to Track ABC.

The above steps would address the basic scenario you have described. However, you additionally mentioned in your last reply that you wish to have a snapshot of every state of the production system after a fix is implemented. I guess you are looking for something like a "label", which you can go back to if you wish to examine the exact state of the project at a certain point in time. DTR currently does not support labels, but to retain such a state you do not need another track - you only need to assemble an SCA (after the fix) and store it in a folder which describes the fix. Later, if you wish to "recreate" this state, you only need to create a copy of track ABC1.0 and import this SCA into the track. (So instead of labelling a state within the system, you will export a certain state and maintain it externally).

Hope that clarifies.

Regards,

Manohar

[Former Member · Accepted solution]

Manohar,

Thank you very much for your detailed reply.

Because I've not had time to try all your suggestions yet (production problems abound!) I've assigned only a few points for now. Once I have time to look into this in more detail I'll assign more if it solves our issues.

Thanks again!!

David