Can I use the CONS Workspace instead of a repair track?

[Former Member]

Hi,

setting up a new track for bugfixes seems in our case a bit oversized. We have new developments that cannot be transported into production at the moment because not finished yet but still need to provide bugfixes for existing programs that are already productive. We have one SC and one track at the moment (we use SP14 of JDI).

So basically we would have 2 states of our software. One development version which includes the newest features and a Productive version which contains the sources that are deployed on the production server. My questions are:

1) Is this recommendable or where are the shortcomings of this approach

2) Must I transport the bugfixes manually to the DEV Workspace by using the function integrate to Workspace or is there any automatic transport between CONS => DEV?

Thanks

David Beisert

[sid-desh · Accepted solution]

Hi David,

You can make use of CONS dev config for making emergency repairs to programs which have been transported to production system.

For a small scenario this is quite ideal where number of DC's that are being developed are not quite huge. The changes that you make in the CONS dev config when activated and released are available under the DEV tab also for import.

While importing in DEV you may be faced with some conflicts in case you have already started modifying the same program in dev config also to provide some new functinality. Under that scenario you may accept/reject that change depending on your requirement.

To make changes in CONS dev config you have to import the dev config with extension *_c in NWDS.

Hope this is what you were looking for.

Regards

Sidharth

[Former Member · Accepted solution]

Hi Siddhart,

thanks for the helpfull answer. This was the exact answer that I was looking for.

rgds

David

[Former Member · Accepted solution]

hi

Just trying to use this thread to validate my view of the consolidation workspace:

1. in case you have configured a consolidation runtime system, you can enjoy a stable system which is not changed as frequently by developers as the DEV system does.

normal development process is that developers check in activites and activate them all the time, which triggers deployemnts to the DEV machine all the time, while the consolidation system is satble until the CMS admin is importing all the changes from DEV into CONS

2. even if you dont have a consolidation runtime system configured, the fact that it is using a seperate set of workspaces can help you fix bugs in production without stopping the development process.

for exmaple, let's assume you have developed an EJB component, imported it to CONS, STG and PROD, and continued your development in DEV.

now a bug in production is identified (in the new EJB)

You can import the cons development configuration, create a project from the inactive ejb component, fix the bug and propogate the change to production.

according to this thread, the change will automatically wait in the DEV import queue, where you can face some merging issues while trying to import.

you can either import the change to DEV and deal with the conflicts or decide that you pass on the import, and fix the bug manually in the DEV

3. in normal cases, there will not be any development made in the cons developemnt configuration

4. when DCs specify dependency to other DCs (in the same track) the changes will be visible once the dependent DC becomes active.

this means that if I added a method to an EJB, and I have another DC in the same track that is depended on that EJB it will be able to use this new method once I activate the EJB DC

If the other DC has specified a dependency to the inactive EJB DC, then it will be able to use my new method once i check it into the DTR

If the Other DC is in another track, it will be able to use my new method only after the Service Pack is imported (thanks to a track connection) into the other track, meaning after my changed EJB is already deployed in production

This means that the import to CONS by itself has no effect on visibility to other DCs.

if it's active, and part of your track (by default or by import) it is visible to your DCs

If any of my statements are inaccurate, please correct me.

Thank you

Zach Engel

Check Point

[Former Member · Accepted solution]

I am not trying to validate Zach's points. But, I have few questions.

1) In your point 2, you said, "<i>even if you dont have a consolidation runtime system configured, the fact that it is using a seperate set of workspaces can help you fix bugs in production without stopping the development process</i>"

How?

2) In my opinion, the scenario you described of fixing PROD bug in CONS wouldn't work under the following condition. I finish all enhancements for a production release, check in, activate, release, assemble as 1.0, testing phase and approve. Later, I start working on dev workspace for the next planned release and continuously check in and activate (auto deploy to dev) and after I finish all the enhancements for release 2.0, I then release these activities, import to cons, assemble and my QA team starts testing on the Test system. At this point of time, I find a bug in PROD which is for release 1.0. I can not use CONS workspace to fix that bug as I already released my 2.0 to CONS.

In this case, I can't use CONS space, am I right?

Thanks,

Kiran

[sid-desh · Accepted solution]

Hi Kiran,

1. The procedure is what i have described in my earlier post.

2. Yes you are right. However if you have to support these many releases then you should effectively manage them using Track connections. Please refer to Manohar's blog below where he mentions you can support up to four releases.

/people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases

Regards

Sidharth

[Former Member · Accepted solution]

Thanks Sidharth,

1. Just making sure my understanding is correct. So, even if we don't have a Consolidation Run time system defined, I would still have the cons workspace, that's very nice.

2. Great weblog from Manohar that I read before. SAP says the server is the way to go even for Java/J2EE apps, I wonder why NWDI and many others aren't documented as well as they should have been. Why does everyone have to depend on forums for simple tasks? Perhaps all this how-to, bestpractice comes from SAP as packaged with the s/w.

My major source of information has been sdn. Thanks to it and all of you.

Kiran

[Former Member · Accepted solution]

Yes you are right

you can only use cons for small bug fixes,

if you have already satrted development in dev, but moved nothing to cons yet.

i agree that this does not happen very often.

I guess the value of cons if you dont have a runtime system cofigured for it is very little

does anyone agree?

[Former Member · Accepted solution]

I don't agree with your last point, Zach. The cons workspace has tremendous value: As you stated yourself before, it allows you to have ongoing development in parallel to fixing bugs in the previous release that is deployed on production. The only issue you have if you don't have a runtime system assigned to this stage is that you cannot test it in a central environment. The developers should have a local WebAS installation though to test all their developments. This production bugfix can also be tested on this WebAS.

[Former Member · Accepted solution]

hi Pascal

Perhaps I am missing something, and perhaps that is because it is not clear to me how does the deployment cycle go.

We deploy a new version of our application every week, since almost every week there are new features ready to be released.

That does not mean we develop every feature in only a week, but it turns out that every week there is some new functionality in the application, and we want to expose it.

under these assumption, what do you think shoud be our deployemnt process?

we are used to working with 3 environments (not including local pcs)

we develop on our PCs

we deploy to DEV early in the week

if there are no issues we deploy to STG

QA check the system

if they find a bug we fix it and deploy to DEV and STG again

QA check the system

QA approve the system

we deploy to production on Sunday morning (IL time)

where do the imports to consolidation fit in this?

when should we import activities to consolidation?

once a day?

once a week?

what are the guidelines?

If i do it everyday, then the info in CONS will not be the same as prod

If I do it once a week (just before i plan to move to STG) i might find issues with imports too late, and my deployment schedule my be postponed...

I will be happy to hear opnions on this

[Former Member · Accepted solution]

If you have no maintenance track, you should perform the import into Consolidation just before you want to test it on STG. That way Cons keeps the same code as Prod as long as possible, allowing you to use Cons to fix bugs that are found in Prod.

You will always have to find a compromise: You say yourself that if you wait too long your deployment schedule might break down if there's a problem with the imports. But what if you import very early in Cons and then find a bug in Prod? You can only handle this with a maintenance track.

There are some guidelines (like <a href="/people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases">Manohar Sreekanth's blog</a>), but you always have to think about what best suits your situation.

Message was edited by: Pascal Willemsen

[Former Member]

Hello David,

I am not sure I understood your scenario. You said you have 2 states of your s/w (latest one and production-ready one), where do you have them? I am assuming one in dev and one is cons.

Ans. 2) You would have to "import" the activities into consolidation manually after you "release" them from Transport view of NWDS.

Though still very rigid, I recommend following SAP's guidelines by creating follow-on track for maintainence. Here's a link on how to implement it. /people/manohar.sreekanth/blog/2005/09/21/best-practicesjdi-branching-patterns-use-cases

In my opinion, you work on cons workspace to fix broken DC cases. But, I am not sure.

Regards,

Kiran