Maintaining transport request move sequence

[Former Member]

Dear All,

Wish you happy new year.

We have one development server (Sandbox), Quality Server then training server and finally production server.

suppose I Developed an application (ALV Report) in development server , then transported it to quality server for testing the same, and again due to some error or change in requirement modified the same  2 -3 times and transported it back into quality server. Now finally solution is accepted by functional person.

here My question is : do I need to keep track of all the Transport Requests from creation of the program to final version. is all the transport request move sequence is required to move the same program into production server.

if yes then from where I can get it as I copied it from SE09. but I feel this is not the correct way to maintain please share if any template or tcode which give u all the sequence of the transport requests for a particular program.

thanks in advance

[ipravir]

Hi Vinay,

Basically we use the SE03 T-Code to get the all TR information of any of the object.

But is display the TR of based on the entered single object.

But in your case, scenario could be different, for the easy solution I can say,

1. Take the Initial TR of the Program (Which Contains the all Programs, Include & other related objects).

2. Then Take the all Final or Last TR of the all objects (if Object had been changed while doing correction).

3. Send the all above TR's in sequence in PRD or Sandbox client.

Note: If any DD (Data Dictionary) object created, then DD respective TR's should be send first.

Regards.

Praveer.

[rajkumarnarasimman]

Hi Vinay,

First of all, whenever we use to make changes in the program, we always keep in our mind that, the TR needs to moved to production system. So the remote comparison in TR should be done before releasing the TR from Dev system. Before releasing the TR, we should merge the recent TR's which is not included in production system.

If proper merge done , then we won't face the problem during importing the TR in PRD System.

In your case, we can use Transport of Copies option to merge the existing TR from Dev. Then we can import the Single TR to production system.

Regards

Rajkumar Narasimman

[matt]

Vinay Kr Chowdhary wrote:

here My question is : do I need to keep track of all the Transport Requests from creation of the program to final version. is all the transport request move sequence is required to move the same program into production server.

Essentially yes. The contents of transport requests are deltas just the changed objects/subobjects/components from the previous version. So for programs, after the initial transport, you only get the actual components touched recorded in a transport.

There are various ways of managing this, which can be automated to an extent. For example:

1. Create a transport

2. Do your work

3. Make a Transport of Copies (ToC) from the transport at 1.

4. Transport the ToC to test. (Never to production).

5. Make fixes (your transport at 1 is still open, so everything can go against that).

6. Go through 3-4 until the testers are happy

7. Release the transport at 1, import into test, import into production.

Message was edited by: Matthew Billingham - removed "delta" from the explanation

[Former Member]

Matthew,

Matthew Billingham wrote:
The contents of transport requests are deltas from the previous version. So for programs, after the initial transport, you only get the actual components touched recorded in a transport.

I'm sure you know in detail, but for the casual reader and newbie, this is more than confusing. I fully agree to the second sentence: The contents of a transport request are the objects changed between the previous transport and this one. However, I would suggest to never call this a delta because it's always an entire program, include, class or whatever other object that is transported. Newcomers often associate "delta transport" with "patches" in the diff/patch sense, so I'd rather avoid that expression when explaining the CTS/TMS.

Best regards

  Volker

[matt]

Volker Wegert wrote:

 However, I would suggest to never call this a delta because it's always an entire program, include, class or whatever other object that is transported.

I agree that delta is not the best description. Perhaps "the changed object/subobject" would be better. Because it isn't the entire program. You create a new report Z_MY_NEW_PROGRAM with include Z_MY_INCLUDE. The entry is

R3TR PROG Z_MY_NEW_PROGRAM

You release that transport and modify the include source code. The new transport contains

LIMU REPS Z_MY_INCLUDE

If you only import into production the second transport, you don't have the complete object.

Similarly with classes, function groups, modules etc.

[ThomasZloch]

If you want to keep it safe and simple for smaller developments, then keep track of all transport requests related to your development and have them imported into production at the same time (STMS will ensure the correct import sequence).

For larger developments, the Transport of Copies approach described by Matthew should be considered.

Further reading:

Thomas