Team Development with DTR

[Former Member]

I am trying to define the standards around which my development group with use the DTR. For various reasons we are not developing using the SAP Component Model hence we will only be using the DTR part of NWDI. I need some guidance. I have read a considerable about of SAP documentation of the various ways to use the different services of NWDI but have not been able to fully answer certain questions.

We are defining the Workspace folders and Workspaces for our various existing application source code. This is a straightward structure since we are not using the SAP Component Model.

Example: Everything is a Workspace Folder except of the 'dev' folders which are the actual workspaces.

NON-COMPONENT-MODEL-APPS

PORTAL-JAVA-APPS

Warrenty-Claims

Module-1

dev

Module-2

dev

Warrenty-URs

Module-1

dev

Module-2

dev

Two questions

1. What would be the best way to track and identify the code that is actually deployed to our dev, qa, and prod servers? Do I create additional workspaces to represent those other environments and somehow copy code from one WS to another once code is promoted through our environments? Any recommendations would be greatly appreciated.

2. As a standard I want to establish that no code is actually checked-in until it passes QA testing. This way no version of code will be versioned in the DTR until it is solid. Developers will use the UPLOAD feature to save in progress development. What I am having trouble figuring out is how to handle the following situation. I have a single project with many different modules that are being developed by different developers. None of their changes are checked-in. How can all of the code be brought together so it can be built and deployed other than resorting to manual means of pulling together the in-progress development. The only way I can figure out to do it would be to have developers check-in their changes then have one developer do a sync and build but then this violates the standard of only checking in QA tested code.

Thanks for any help.

Dean Cyril Wood

[sid-desh · Accepted solution]

Hi Dean,

What i feel is you have can have three workspaces DEV QA and PROD for all kinds of applications.

Let the developers check-in the code in the dev workspace. Using scripts you can then integrate the code from DEV workspace to QA where it can be tested and then again integrate it to PROD.

Or another option could be to have something similar to when you create tracks. Have a DEV workspace folder under that you have ACTIVE and INACTIVE workspace. Developers check-in the code to inactive workspace from where you can integrate it to Active workspace. Where it can QA'ed and tested and then deployed.

I feel if you have too many workspaces (for each module) soon it may become quite difficult to manage.

Also having two workspaces is beneficial as then you two separate paths. Ofcourse the user will have to check-in the code to INACTIVE workspace. But then the QA will consider ACTIVE workspace as the source which needs to be QA'ed.

Regards

Sidharth