Track design in a complex transport landscape

Question

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 transport to mulitple systems
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.

Answer 1

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