best practice for releases/iterations

[Former Member]

I'm working with scenario 2+. I read all the tutorials and articles about JDI and branches (https://www.sdn.sap.com/irj/sdn/weblogs?

blog=/pub/wlg/2408) but I couldn’t find the answer about how to approach small versions and releases. Working with JDI, what is the best practice for small versions and for releases? Should I create a new track/branch for each release (1.0, 2.0) ? What should I do for iterations/small versions (1.1, 1.2, 2.1)? Could you tag a group of DCs so then you could return to that tagged version?

Thanks a lot for your reply!

[htammen]

Hi Deborah,

how you deal with SCs, SC versions and tracks depends on your use case.

If you are doing in-house-development there is often no need to maintain other than the last release. So you can work with one SC version and one track. But you can also work with several SC versions and tracks. This enables you to come back to a former release (or version) if you made some critical errors.

If you write software for different customers you always have to create a new SC version (1.0, 1.1, 1.2, 2.0, ...) and then a new track if you implement new features. Your old releases have to be maintained. So you have to have a track as a basis for maintance.

If you say 'My customers always get the latest release even if they did not pay for the new features' you can of course work with a lower amount of SC versions and tracks.

The answer to your question 'Could you tag a group of DCs...' is: NO.

You have to create a new SC version and a new track.

There may also be other approaches but I hope this helps a bit.

Regards

Helmut

[Former Member]

Thanks a lot for your reply Helmut!

I am doing in-house-development (one client). But I'd like to identify specific versions so I am able to come back to a specific release, for example, to deploy in testing an old release or version for checking some feature or bug in particular.

Considering that's the case:

- should I have one track with multiple SC versions? How do you add new SC versions to a track?

- or would it be better to have one track for each version or release? In this case, I'd have to create a new track (1.1) "saving as" the old track(1.0) to the new track (1.1). And connect the tracks with repair and transport connections. is this correct? How the SC versions come into play?

thanks again!

[Former Member]

You cannot have multiple versions of the same SC in one track. I guess this answers your question.

[htammen]

Hi Deborah,

as Pascal already mentioned you cannot have multiple SC versions in one track. So you have to create a new track for each SC version.

Regarding your second issue I would say that it is not necessary to connect the track of SC 1.0 with the track of SC verion 1.1 with a transport or repair connection.

If you just want to be able to deploy an older version for checking the functionality you can check it and then do the repairs in a newer track. This way you save the state of your older version (with all enclosed errors of course). If you do the repair in the older version and connect the older and newer track via a transport connection you loose the state of the older version and cannot deploy the exact state of the once used version (this is not totally correct, you can but have to manage it yourself).

But from my experience this is sometimes necessary to show customers (even in-house customers) the functionality of old software versions.

Regards

Helmut

[Former Member]

OK. I understood. Now, what is the difference between a release level (think that is the same as SC version), support package and patch level?

Are they different levels of a version of a product? If that's the case, I can create a SC version declared in a track, and create new tracks with new SC versions for each big change of the product. And for minor changes, set a different support package or patch level when assembly the components.

If all this is true, will I be able to retrieve a SC with a different SP or patch level?

[htammen]

Hi Deborah,

think of Web AS itself.

NW04s uses a new release 7.0. NW04 uses the release 6.40

A new release reflects major changes.

NW04 did have different SPs (support packages) from SP04 to SP15.

A SP reflects minor enhancements and new features.

Within a SP you can have serveral Patch Level which are released to correct errors in that SP.

Regards

Helmut

[Former Member]

Thanks again! You are really helping me.

Two more questions:

1- Considering I have one track per release, should they have two different SC versions?

2- Considering I work with only one track, if I have multiple assembled SP and/or patch levels, I know that a .sca file is created per "Assembled components".

a- Will I be able to redeploy an old assembled component?

b- Will I be able to see the source of an old assembled component? Maybe through re-import of the .sca file in the check-in tab as an archive. In this case, maybe I can see the two versions of my SC in the same dev configuration in the IDE. is this possible?

thanks again!

[htammen]

Hi Deborah,

1- That depends on what kind of track it is. If it´s an repair track the SC version should be the same. If you implement new features you should use a new SC version.

2-

a- Yes. The assembled .sca files resides in /usr/sap/JTrans/archives. The name of the archive file is something like

_<SC>.sca

b- YES and NO. You can import the .sca file into a new track in the check-in tab. As far as I know you cannot import it into a track that already encloses this SC and therfore you cannot see the two different versions of your DC.

If this would be possible it would lead to a lot of follow-on problems. Which DCs should be deployed on the runtime systems? You have to keep in mind that a DC with a given name can be deployed only once on a runtime system.

Regards

Helmut