How do you move changes from your project developments into the maintenance development system?

[former_member187281]

Good day colleagues.

We are in the process of introducing retrofit, and the picture is clear for us, generally speaking, to retrofit the project landscape with the changes done in the maintenance landscape.

What about the other way around? We mean, when the project is set to Go Live, we understand the transports will be all added, e.g. to the Production System buffer to be moved there via Maintenance Cycle, based on the way we defined the project and the logical component being used.

However, how do you feed those project transports to your Maintenance Development System using ChaRM?  or do you do that Manually?  We doubt. Copying Production back into Development?  no way !!!

How do you establish that?  We have a sort of idea but the documents about retrofit only seem to talk about moving transports one way, as far as we have found.

Many thanks for any feedback.

Juan Carlos

[Vivek_Hegde · Accepted solution]

Hi,

As far I have seen, it is a manual process via cutovers. We add those TRs to Maint DEV system manually and repackage them so as to reduce the number of TRs. Then the normal charm procedure is followed in Maint landscape to move them to PRD. In some blogs I also read about adding these TRs to import buffer of all Maint. systems (DEV, QAS, PRD) and importing them directly (not through charm). However I am not very sure about the latter method.

\

Regards,

Vivek

[former_member187281 · Accepted solution]

Many thanks Vivek for your feedback.  We will go on to some rounds of testing and will complement how to resolve this.  It seems that through ChaRM you can achieve moving the transports back to the Maintenance Development System.  We are very positive it is possible, based on what we configured.

You confirm the cutover is a manual process, but ChaRM can automate importing into the maintenance landscape.

Regards,

Juan

[former_member187281 · Accepted solution]

We are preparing a blog with our solution, which covers the projects, logical components, some parallel RfCs, the cutover process, the re-packaging of the transports in the maintenance development and the move up stream to Production.

Regards,

Juan

[former_member206271 · Accepted solution]

Hi Juan,

Thanks a lot for raising this question.

We also want to have proper configuration and solution for Cutover process through ChaRM.

If you have done it , can you please share the Blog.

Thanks,

Piyush

[former_member187281 · Accepted solution]

Hi Piyush.

I apologize for a late close on this questioning about moving projects back into the maintenance stream.

Basically there are 2 solutions as far as we know:

1. What Vivek mentions, which is performing a cutover and repacking the project transports into 2 transports in the maintenance stream:  A workbench and a customizing.   In that sense, at the end of the day you end up moving just 2 transports to the maintenance stream up to Production.   They contain all your project objects.  Thanks to Vivek, again.

This is a very practical and interesting approach.  The only reason we did not adopt it, is based on the fact that if by any chance we encounter an issue with a project transport object in the maintenance stream (Dev or QA), now that all is bundled together, we may be stuck right at the time weare getting ready to GoLive.  How tough is going to be that issue? how easy and quick to fix?how much would that affect the whole project time frame?   Those questions made us decide to option 2.

2.  What we are doing is that at cutover we move at the same time all project transports to the transport buffer of each of the maintenance stream systems (Dev, QA, and Prod).   We first open the gate to move the transports to Dev and we test, then to QA and we test, as well.  If there may be an issue, and the issue can not be quickly resolved by the project team, we can go up to the extreme of using a new feature introduced in ChaRM in SP10, if we are not wrong, but definitely available in SP12.  That feature provides a way to selectively decide which transports of the release are to Go Live and which ones do not, although we have no had to use that feature, yet, but it is there.

We do not see any risk on adding the transports to the maintenance buffers at the same time.  There are ways to control the systems that are open for receiving transports, and the project phases, which guarantees no room for error.  There have to be deliberate actions taken (more than one in our case), to wrongly move a project to GoLive before its time comes.

That is more or less the scenario Piyush.    

Hope that explains the scenario.  So far no decision on really publishing as a blog.  It seems not to be written on stone, as consulting with different companies, each adds its own flavor to the recipe and shuffle ideas to get to what they are looking for and makes them happy.

Juan

[former_member206271 · Accepted solution]

Thanks a lot Juan,

Really appreciate your reply.

Piyush

[former_member187281 · Accepted solution]

Good morning Piyush:

Another thing I for got to mention is that Vivek's approach works perfectly when the owner of your objects is the Development System of the Maintenance Stream, what he calls DVA in his diagram. That is the advantage of repacking the objects there, as DVA remains the owner or takes ownership of any object that arrives from the Project Stream.

In our case, the owner of the objects is the Development System of the Project Stream (DGD in Vivek's diagram).  Another reason why repacking was not going to work for us.

We decided to have only one Development system as the owner of all customer objects.

Regards,

Juan Carlos

[former_member206271 · Accepted solution]

Yes Juan,

In our case as well, the Project objects going live will be from Development system of Project landscape.

Thanks again,

Piyush