Making changes at different stages of Development Track

[Former Member]

This is a general question. I was wondering what Configuration needs to be imported into NWDS at different stages of Development Track with let's say 3 run time systems, dev-test-prod, defined per track. When i start the development i will import _dev configuration and add DCs, But not sure which configuration to be downloaded at the other sages. Post activation modifications, post release modifications etc..

Thanks and Best Regards

Firasath Riyaz.

[Former Member · Accepted solution]

Hi Firasath

The way to approach is it to use the development configuration for the Development workspace(_dev_D) . Make your changes here and then propagate your changes to other workspaces/runtime systems. Very rarely will you need to obtain development configuration from consolidation workspace( consD) for changes.

How the whole process hangs together is provided in this scenario and what happens post activation and post release.

http://help.sap.com/saphelp_nw04/helpdata/en/71/384c4005a99523e10000000a1550b0/frameset.htm

Regards

Pran

[Former Member]

Hi Firasath,

In your scenario, its always the _dev configuration that you work on. Activation doesnot result in a new configuration but a release or a system restore results in a new dev configuration. Since you'd already have a dev configuration not importing the new dev configuration does not hurt.

If you have DEV & TEST both on the same server it is only an overhead (because the same source is activated in DEV/ consolidated again for CONS/ rebuilt & redeployed again for TEST).

Hope this makes sense,

Regards,

Rajit

[Former Member]

Thanks for a quick reply Gentlemen,

Pascal i have gone through few of those weblogs before.. Rest i shall take a look.

DJ My question was in the context that, i have followed the scenario 3 tutorial for Development of techno and appl described on help.sap.com. In this tutorial i never came across a scenario where i need to import configuration back after i have, lets say activated the changes or may be after releasing the changes. If one comes across such a situation what configuration one needs to import from sld?

Hope i make myself clear? My apologies for the confusion.

Also what happens if one uses the same system for both dev and test, does the component get deployed multiple times on the same machine? I am squeezing in this question here, not sure if should do that or start a new thread.

Thanks and best regards.

Firasath Riyaz.

[Former Member]

Hi Firasath

Hmm .. Development configuration is only a description and indication to NWDS to what the CMS , CBS and Workspaces are . I am wondering what is the use case of importing a dev configuration after a release because you would be already working with a dev configuration for developing the application?

Yes it would get deployed on the same machine. But the fact that you are going to use a server for both DEV and TEST indicates the scale of the project to be a small one , also may be having limited number of developers. In such cases it is better to go for Scenario 1.

Other alternative would be to define DEV as your own machine and TEST as the server at hand.

Regards

Pran

[Former Member]

HI Riyaz

I did not got your statement "which configuration to be downloaded at the other sages. Post activation modifications, post release modifications etc."

In JDI you create one track which has DEV-TEST-PROD systems.

And in NWDS we can import only two workspaces DEV and CONS.

[Former Member]

Some useful SDN links:

http://www.sdn.sap.com/irj/sdn?rid=/webcontent/uuid/033cabec-0701-0010-5a93-b2776c29d65e">sap [original link is broken] [original link is broken]

<a href="/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-ongoing-development">Best practices for NWDI: Track design for ongoing development</a>

<a href="/people/guenter.schiele/blog/2005/12/21/best-practices-for-running-the-nwdi">Best Practices for Running the NWDI</a>

[url=/people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases]Best Practices@JDI : Branching Patterns & Use Cases[/url]