Skip to Content

Dual Track Tansport Landscapes with 6 systems - where to place pre-prod

HI

We are currently running a Dual Track transport landscape with 6 systems, with landscape A  ( Production Support) being made up of 4 instances  --- DEV(BAU), QAS(BAU), Pre-PROD(BAU) and PROD(BAU) and landscape B (Project Development) containing DEV(PROJ) and QAS(PROJ).

Our releases, are made up of Emergency, Standard, Minor and Major. The first three originate in the production support landscape, and via a custom Retrofit process are sync into the project Landscape (hopefully we will move to SAP's retrofit process in the near future). Major releases originate on the project development landscape.....and then are transports into BAU landscape (again where a custom retrofit process takes place).

I can see the  benefits  of having Pre-Prod connected to either landscape. In SAP's "Two value releases per year" (White Paper)  ....it has Pre-Prod by default on the Project Development landscape.......

Our Pre-Prod systems have the luxury of replicating   a number of external connections to other systems, so our testing can be as close as we can get to prod. Something harder to do in the pure QAS environment on either landscape.

My question where is it  best to place Pre-Prod system i.e. in which landscape?......Production Support (where it is currently sits) or Project Support where SAP seems to be suggesting via the white paper "Two Value Release per year".....Page 18 to 23?

One of the benefits I see of having it on its current landscape(Prod Support) is that Emergency, Standard and Minor releases...or get a dress rehearsal of being imported into an environment(Pre-Prod)  that is as close to Production as we can get. For Major releases we still move these from the project landscape DEV(Proj)=> QAS(Proj)=>  and then back through into DEV(Production Support),-----Object ownership is adjusted.....then it is transported into => QAS(BAU)....(regression testing happens) ====> and then finally into Pre-Prod...both as a dress rehearsal for "Go Live"  and  for User Acceptance testing by the Business.....and then Finally into prod. I suppose it is a larger overhead than just going

DEV(Proj)=> QAS(Proj)=> Pred prod => prod

So interested in anyone running the  Dual Track Transport Landscape(6 systems) - where you have  placed "Pre-Prod"...pros and cons you see or have found?

e.g.

DEV(Prod. Support) => QAS(Prod Support)=> Pre prod(Prod Support) and then Production

or place Pre prod on the Project Support landscape

DEV (Proj Support) => QAS(Proj Support) and then into Pre-prod  => Production

Thoughts, especially if you are running  a  6 system Dual Track Landscape.

Cheers

Peter

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Dec 22, 2014 at 12:45 PM

    The purpose of having pre-prod is so that as your import transports via an entire project, you iron out overtaker transports.

    As it is typically expected to be refreshed from Prod on a more frequent basis than QA; it brings you closer to stability within Prod.

    As for placement of the pre-prod system, if you have the same TMS DC you can set routes up from both tracks.  If you have to have two different DCs, then I would point out that you would have far more transports being imported from the project side than the maintenance side; as you only have that track around for having identical object versioning for Prod.

    Add comment
    10|10000 characters needed characters exceeded

    • So my question to you is why are you transporting into another Dev system after the proj QA release?  The SAP E2E200 session points you to having a project landscape go to pre-prod only to validate that the changes don't cause chaos within production.

      If you have constant changes occurring on your BAU track, then you should be retrofitting into your project track to avoid overtaker effects on the project imports.

      Then after your project transport into Prod, you take the project dev/QA systems and refresh them back to BAU to keep object versions in line with production.

      One bad thing (imo) about how your transport process is currently, is that your objects in Dev BAU are not in sync with Prod for a short time.  And then you are prone to an overtaker transport if an emergency one takes place while testing of the project transport is still on QA BAU.  While pre-prod would catch this for, you still have the potential for a 'perfect storm' event even on pre-prod.  Ideally you want to get approved changes to production as soon as possible to keep everything in sync.