Basic understanding question regarding developing lifecycle

[Former Member]

Hi,

i'm working for just 2 weeks with NWDI and have some basic understanding questions:

- The lifecycle for developing is to check out, make the changes locally, deploy to server (dev and cons), and then check-in to NWDI. Would it not better first to check-in the ressources and then to deploy these central ressources?? In common way, you cannot be sure that sources stored in NWDI are deployed!?

- regarding point 1: i can deploy files on dev server, make local changes and deploy a newer version directly to cons server! that makes no sense to me. I come from ABAP Size where you can only transport to cons server the files from dev server

ABAP

DEV --> CONS

Java WD

DEV <-- LOCAL --> CONS

- i have today a tested version of my application deployed to cons server. In case i deploy tomorrow a newer version with error, how can i get thet version from yesterday? can those "milestone" versions be marked or re-deployed easily?

- by check-in, there is a popup for activating? What is exactly done with that activation?

- I have access to tracks "xyz_dev" and "xyz_cons", i work in dev track, why/when do i need the cons track?

[Former Member · Accepted solution]

If you deploy directly from NWDS, you are bypassing the NWDI controlled deployment. Deployment from NWDS is only intended for local Java systems or if you're not using NWDI.

NWDI will deploy to the track's development or consolidation system once you activate your activity.

The common way of working is as follows:

1. Create a project/DC to work on (this performs a checkout in case the DC already exists) from the _dev Development Configuration

2. Develop the DC(s)

3. Build the DC(s) locally in NWDS

4. Deploy to a local WebAS (which is not a runtime system in the track definition) for local testing. This is an optional step.

5. Local testing - optional.

6. Check-in activity. This stores your sources with new version numbers in the DTR.

7. Activate activity/activities. This deploys to the Development runtime system of the track if the CBS build is successful in case you are working in the _dev Development Configuration. Deploys to your Consolidation runtime systems if you are working in the _cons Development Configuration.

8. Test on Development system. OK: go to step 9. Not OK: go back to step 1 or 2.

9. Release activity/activities for transport in NWDS

10. Transport to Consolidation using CMS Transport Studio.

11. Test on Consolidation system. OK: go to step 12. Not OK: go back to step 1 or 2 using either the _dev or _cons Development Configuration, depending on your environment.

12. Assemble the SC in CMS Transport Studio

13. Transport to Test using CMS Transport Studio.

14. Test on Test system. OK: go to step 15. Not OK: go back to step 2 using either the _dev or _cons and Reject the SC release in the Approval tab of CMS Transport Studio.

15. Approve the SC release in CMS Transport Studio.

16. Transport to Production system.

Note that all runtime systems are optional and that some steps testing steps can be omitted if no runtime system is defined for a certain track stage.

[Former Member · Accepted solution]

Thanks for this great answer Pascal.

Do you have a guide or a documentation regarding this process, can't find so specific information, only the basic information about what nwdi is and what components are integrated...

[Former Member · Accepted solution]

Here's a starting point: [original link is broken]

[Former Member · Accepted solution]

One Last question:

- Deploy to Cons Server happens by Activate + Release Transport

how works the deployment to Dev Server? Automatically by Activate??

[Former Member · Accepted solution]

When you activate an activity in a Development Configuration the CBS builds the involved DCs. If this is successful it triggers deployment to the corresponding runtime system (unless "Disable automatic deployment" is enabled in the runtime system configuration of the track).

Release for transport makes the transport available in the next queue of the track: Consolidation import queue if the activities reside in the _dev Development Configuration; Assembly and Development import queues if the activities reside in the _cons Development Configuration.

Edited by: Pascal Willemsen on Jun 12, 2008 3:44 PM

[Former Member]

Christopher,

I think an important part of your question is missed.

The names DEV/CONS/TEST in the NWDI do not in any way directly relate to real SAP systems.

Any system can be linked to DEV ... or no system. You can link the CONS track to a portal development system for example.

Taking it one step further, you can in fact release your SCA from the test track to be deployed to your development portal so it is an SCA that gets delivered there and CTS+ can then move the SCA throug the landscape.

I think there is a lot for you to learn and the links are already given... just lots of practice for you now