Track design in a complex transport landscape

[Former Member]

I have read the blog for <a href="/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-ongoing-development Best Practice</a>

I have read the online help for <a href="http://help.sap.com/saphelp_nw04/helpdata/en/42/f1a03611d83ee4e10000000a1553f7/content.htm">Deployment to multiple Production systems</a> and

I am a Basis person that has set up and used NWDI before but now have a scenario that is becoming quite common in the real world.

One of our customers have a Development/QAS system for not only maintenance but small projects as well. They also have a devleopment/QAS system for large projects (and also horrifically in the near future probably also have a short term dev/QAS for a CRM implementation).

All of these Dev/QAS systems feed into a pre production QAS system that then releases to a production and training master system.

Naturally I want to know how best to set up my tracks.

My thoughts are that we can have 3 scenarios.

1. All changes made to the maintenance track are also applied to the other tracks manually. (this is SAP's recommenadation for ABAP transports)

2. All Changes to DC's in the maintenance track are manually imported into the other tracks when dev activation is successful.

3. The project track depends on the Maint track

There are complex issues with all of these so I would realy appreciate a best design dicussion for this complex matter.

[sid-desh · Accepted solution]

Hi Graham,

If my understanding is correct then i would have a track design given below:

1. Track 1 - small projects (DEV/QA) - Runtime systems (DEV OR CONS and TEST)

2. Track 2 - large projects (DEV/QA) - Runtime systems (DEV OR CONS and TEST)

3. Track 3 - short term CRM projects (DEV/QA) - Runtime systems (DEV OR CONS and TEST)

3. Track 4 - Pre Prod and Production - Runtime Systems (TEST and PROD)

Transport Targets

Track 1 - Track 4

Track 2 - Track 4

Track 3 - Track 4

Here i have assumed that code from all tracks must feed into only track 4.

Now with this i feel if we can take the discussion forward and i am sure other members will also present their views and opinions.

Regards

Sidharth

[Former Member]

The Scenario we have is common now adays and we have a few clients with it. SAP call it a Complex System Landscape.

In this case there is

PTD and PTQ systems for dev. and QA of maint. and small projects

PT1 and PT2 systems for dev. and QA of large projects

Both PTQ and PT2 then feed PTR - a pre production QAS system

PTR then delivers to PTP (production) and PTE (training master)

The customer is also looking at an additional dev & QA to give us real headaches.

It looks like the best scenario possible is as below that is not 100% watertight but pretty good.

Track 1 - Contains PTD and PTQ

Track 2 - Contains PT1 and PT2 with a connection type Repair from Track 1

Track 3 - Contains PTR PTP with a connection type Transport from Tracks 1 and 2.

Note:

The configuration of Track2 repair connection is as per document <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/73/cf61253f4c4536b5047faf6e9e7f71/content.htm">Back Transports</a>

The configuration of Track3 is as per document <a href="http://help.sap.com/saphelp_nw04/helpdata/en/42/f1a03611d83ee4e10000000a1553f7/content.htm">Deployment to multiple Production systems</a>

Any feedback?

[Former Member]

think I have found the answer in the back transports.

Tracks 1,2 and 3 all transport to 4 but track 1 can have a repair type connection to 2 which can have a repair type connection to 3.... would this make sense?

As far as minimising tracks I would gladly agree to this if you could come up with a suggestion.

We have a few clients with a DEV and QA system and also a Project dev and a project QA system. I cannot see how we can not have seperate tracks for these as projects do not often go into production. I complicated matters overly by adding a CRM track our customer is thinking of also having, apologies for this, it just makes the dicussion more complex, please ignore track 3.

[sid-desh]

Hi Graham,

I will be honest that i may not have understood your scenario completely. However are the DEV and QA systems same for all projects. Is there a possibility that you have separate SC's in one/two tracks with each SC formed in such a manner that you dont have to develop the same DC in two tracks.

In case you have dependencies between different DC's (which are in different SC's) declare a usage dependency in SLD.

What i am trying t suggest is that one DC be developed in one SC and one track only there repair/forward case is avoided.

Regards

Sidharth

[Former Member]

Hi Sidharth,

Many many thanks for your prompt and excellent start to this. I agree this will be fruitful to all.

The structure you propose is the only logical one. The problem comes with keeping the tracks and the environments in Sync.

For this customer;

1. The changes in track 1 must also be made to 2 & 3

2. The changes in track 2 must also be made to track 3

Naturally the changes to the tracks must ensure that newer versions do not get updated with older versions. With SLD registration, assembly versioning and all 2 tracks merging into a pre prod this should be avoided from that standpoint.

My concern is that there would be some chances of versions going astray a bit depending on how they link together.

For example track 1 & 2 have version 1.1 of a DC.

In track 1 they start making a Fix to a bug and version 1.2 of a DC is created.

In track 2 they start making a large project change and version 1.3 of the DC is created.

Track 1 releases Version 1.2 into preproduction and also into track 2.

Track 2 releases version 1.3 into preproduction but this does not have the changes in version 1.2

If testing is not vigorous in pre production the fix will be backed out of in production. Now I agree that version 1.4 in track 2 will have these changes in it but there will be a time when production has the bug reversed and this will cause confusion. possible resolution I see all apears to be manual and require trust.

1. Changes to track 1 are also made manually to track 2 and 3 at the same time.

2. Changes to track 1 at dev activation time can somehow be propogated to track 2 and 3. (Can you import DC's?)

3. Release from track 2 in the above example would require version comparison along the track to ensure no new versions come from other tracks.

Apologies if I misunderstand any of the logistics, please feel free to correct any assumptions I have. It is important that transports are handled in the safest way possible.

regards

Graham

[sid-desh]

Hi Graham,

There seems to me that one particular DC is being developed in 3 separate tracks. This is because you have written:

<i>1. The changes in track 1 must also be made to 2 & 3

2. The changes in track 2 must also be made to track 3</i>

I feel our first should be to minimize the numbers of tracks being used. If we have many tracks only due to the fact that there are many runtime systems then we can think of other alternatives.

In the mean time i would also like to bring to your attention that CMS/CBS and DTR offers certain command line tools which can be used in scripts for various purpose. Links to command line tools is <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/61/1c57428a070e53e10000000a155106/content.htm">here</a>

Also there is blog written by David Beissert about how he automated the deployment of SC's using ant scripts. I request you to please search for that blog and have look.

I have made these points so that you can start to think of alternatives. Trying to reduce the number of tracks should give us more clarity.

Regards

Sidharth