Track strategy

[Former Member]

If I want to transport PAR's and EPA's from dev-qa-prod using NWDI, what is the best practice in real time scenario's ?

i.e. to create two tracks, one having SC with EPA DC's and other having an SC with PAR DC's

or

to create a single track with one SC and all the PAR DC'S AND EPA DC'S

Thank you

[Former Member · Accepted solution]

If the EPA's are highly dependent on the PAR's, I think it's best to use one SC. That way it's a lot easier to combine related EPA and PAR DC updates into activities, transports and SC releases: There will be only one transport after the Assembly stage. When using two SC's you'd also get 2 transports after the Assembly stage, which could result in errors in your portals for a short period of time, if your Basis team can't manage to import them properly.

[Former Member · Accepted solution]

Hi Pascal,

Thank you for the reply and sorry for delay in updating this thread. what I think is that it is good to have two SC's one having PAR DC's and other having EPA DC's, the reason being that we update the PAR DC's frequently and EPA DC's very rare. i.e. separation of content from code. I hope you agree on this. clarify me if i am wrong as I am also not that much experienced in JDI.

Now my question is should I place those two SC's in one track or is it better to maintain two seperate tracks. what would be the the ideal one. i.e. if I keep both of them in one track and update a PAR file in one SC, is it going to update the other SC in the assembly step?

could you please clarify this to me.

Thank you

[Former Member · Accepted solution]

There are arguments for both concepts... You could state that if you use one SC, you can still separate code from content, because you can put the EPA's and PAR's in separate DC's. If you use two SC's: Is there any other SC that will/might use DC's from one of those 2. If there is, then there's a good reason for the split. If not, why split up?

You should only put SC's together in one track if they have the same software lifecycle.

[htammen · Accepted solution]

Hi Reddy,

I aggre with Pascal. One SC is sufficient even if you do more updates at the PAR Dcs. SDM will not deploy DCs that were not changed.

If you create too many SCs you get lost in a bunch of SCs by the time or you have to document what you do very well.

Have a look at SAP. They deploy just three SCs: SAP-JEE, SAP_BUILDT and SAP_JTECHS. These three contain all you need to develop and run your J2EE applications.

Regards

Helmut

[Former Member · Accepted solution]

Hi Pascal and Helmut,

Thank you for the replies. Could you please have a look at the following page, which just states an interesting point regarding portal applications.

http://help.sap.com/saphelp_erp2005/helpdata/en/95/226c42eed40e53e10000000a155106/content.htm

<b>"You should not mix Portal Business packages you develop with applications, because the portal content is updated more often than the functions of the application"</b>

As far as I understood, although deployement is not a problem when there are many DC's in a SC if only one DC changes, but the assembly is going to take a lot of time as it depends on number of DC's.

one more question

if I have a track with two SC's, each one having some DC's and if i change one DC in one SC, will both of the SC's built when i run the assembly step.

could you please clarify

Thank you

P.S: this is the last question..will close the thread...sorry for extending it.

[htammen · Accepted solution]

Hi Reddy,

you can select the SC you want to build via a DropDownBox in CMS at the assembly tab.

Regards

Helmut

P.S.: I think that there could be more discussions like this about conceptual items because this clarifies the concepts an usage of NWDI.

[Former Member · Accepted solution]

Assembly assembles only the SC's that are touched by the transport that you are assembling. And since you cannot combine activities from multiple SC's into one transport, a transport always assembles only one SC.

Next to that, it doesn't make sense to assemble other SC's as well if they are not affected by the update. If a dependent SC is affected however (because you changed the calling interface of some Java class in a DC of the SC it depends on), then you will have a separate transport for that SC to cope with that change as explained above.

[Former Member · Accepted solution]

Thank you for the clarification Helmut and Pascal

Points assigned

[sid-desh]

Hi Reddy,

In my opinion this depends on how you are going to maintain all the DC's. Please refer to this blog by Manohar which describes how you can play with Track's.

/people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases

Also it will be better if you have two separate tracks for developments.

Regards

Sidharth