Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Designing NWDI Tracks

We are just getting started with NWDI, and are considering how to design our tracks. The majority of our custom development will be in Web Dynpro for Java. My question is on how many tracks to create over the lifecycle of a piece of software.

For example, let’s say that you have developed a Web Dynpro for Java application, and expect its total useful life to be 3 years, with a major release of changes every year, and bug fixes occurring frequently throughout its lifecycle.

Would you create tracks such as follows?

<u>Year 1:</u>

Development Track 1

Maintenance Track 1 (repair track connection to Development Track 1)

<u>Year 2:</u>

Development Track 2 (track connection from Development Track 1)

Maintenance Track 2 (repair track connection to Development Track 2)

<u>Year 3:</u>

Development Track 3 (track connection from Development Track 2)

Maintenance Track 3 (repair track connection to Development Track 3)

This (I think) would create a version of the delivered code for each major release in the Development Tracks, and allow for parallel development for bug fixes in the Maintenance Tracks….but I’m not sure if this is overkill.

Ideally what we want is an easy way to go back to a previous version of a piece of software if we have to, without having to dig through the DTR and revert changes at the file level.

Does anyone have a way to do this?

Thanks in advance,

Chris

Former Member
Former Member replied

Chris. We did try the "different software component for each version" option too. I can't remember the details but we scrapped that idea also. Part of it was because it also required Basis to do a lot of extra work.

We came from WebSphere and there the developer could do their own versioning without having to involve some admin group. Our Bais team is short-handed and overworked so they balked at all the overhead.

Also, at some point someone just took a step back and said "Have we ever actually HAD to go back to an old version of the system?" The answer was No. So then it was obvious that, even though it is nice to have the feature, all the extra work just wasn't justifiable.

Of course, then you take a chance that some day in the future you WILL be asked to go back and you won't be able to.

Something we have on our todo list is to test restoring a system using the SCA file(s) that are generated during the transport. Apparently, those ARE versioned somewhere inside the CBS/CMS (I can't ever keep the two straight).

Also, from what I understand and what I've seen when watching the Basis team do transports, there are versions created internally as code is imported into some queue. I know I'm mangling the terminology but the point is that there may be some other options here.

The big problem is that there doesn't seem to be ANYONE who really knows the whole process, understands it, understands this requirement and can analyze it all to come up with a good solution.

If you'd like to share info offline let me know. It's really nice to finally see some other people on here who are going through the same things we are/were. When we started, it seemed that we were all alone. Last year at TechEd I roamed the halls and presentations : ) looking for people in the same situation but it just seemed there weren't any.

David.

0 View this answer in context

Helpful Answer

by
Not what you were looking for? View more on this topic or Ask a question