DEV - The Forgotten Environment - UDCs VERS Data

[johndanter]

Hi folks,

Nearly every site/customer I've worked on forgets about DEV. Be this versions, test data, UDC etc. Then us lowly developers are asked to test why something doesn't work and we don't have the versions created in PY/CRP.

My main concern is versions

Now data refreshes can take care of the UDCs and data etc, but how do people tackle versions that analysts and testers will be creating in PY/CRP?

Discuss....

Thanks in advance for you input

John

 

[jdelisths]

One of our clients made a modification to the versions app to put all Versions changes (data selection, sequencing and PO) and additions (that occur in PD) into an OMW project (with a soft coded name). Periodically, their CNC admin reviews this and demotes those versions back to PY and DV.

I am sure there are other ways to handle this ...

 

[Chan Rana]

We do versions only thru OMW so they are all same in all environments due to strict change control.

Chan

 

[nkuebelbeck]

We do versions only thru OMW so they are all same in all environments due to strict change control.

Chan

this is how we operate. works well.

 

[Larry_Jones]

We here have versions locked down pretty tight and treated like regular apps (for promotion) for the most part.
Only a few UBEs allow users to access / change processing options and data selection on others is locked down to only the minimum required to perform the function.

 

[BOster]

We do versions only thru OMW so they are all same in all environments due to strict change control.

Chan

this is how we operate. works well.

As do we... except for when we don't. Inevitably, it seems, somehow versions in PD get out of sync with DV. I would be curious as well to see how others do a "version" copy from PD to DV.

 

[jdelisths]

Hi Brian - See my previous response. This method has been working very well for this client for over 7 years now. This allows power users to create/change versions without hassling IT.

 

[johndanter]

Thanks for the replies, keep em coming.

Are you guys saying you do actually get people to start in DV anyway. And that's how you get around it?

I think I'd get resistance to that, so what options (apart from modifying the OMW screens) would I have to keep them in synch

 

[Gomer79]

I have to echo the comments of others that we promote versions from DV to PY to PD or if there is a rush PO change IS makes the change in all environments. We have a handful of exceptions where users can adjust the POs but not many.

 

[BOster]

One of our clients made a modification to the versions app to put all Versions changes (data selection, sequencing and PO) and additions (that occur in PD) into an OMW project (with a soft coded name). Periodically, their CNC admin reviews this and demotes those versions back to PY and DV.

Hi Brian - See my previous response. This method has been working very well for this client for over 7 years now. This allows power users to create/change versions without hassling IT.

That is a pretty ingenious solution and would definitely be a way to keep things in sync going forward. I was more wondering about best practices to sync things back up when, for whatever reason, they get out of sync... even changing things in DV or TS/PY for testing purposes for example. We may do a bunch of configuration changes in DV or TS/PY and then things never get put back the way it is in PD.

 

[Larry_Jones]

John,

in our case users don't have access to BV or IV (or OMW). Only IT can create/modify versions other than the few cases where at runtime users can modify Processing Options.
In our opinion we've avoided a lot of disasters this way from users testing options in production.

 

[johndanter]

One of our clients made a modification to the versions app to put all Versions changes (data selection, sequencing and PO) and additions (that occur in PD) into an OMW project (with a soft coded name). Periodically, their CNC admin reviews this and demotes those versions back to PY and DV.

I am sure there are other ways to handle this ...

Thanks for this.

I was thinking of using OMW activity rules to hopefully do the same thing when it's promoted?

 

[BOster]

Thanks for this.

I was thinking of using OMW activity rules to hopefully do the same thing when it's promoted?

That is basically how we have things setup. When versions get promoted up they copy back down to lower environments. The problem comes though when in either DV or TS/PY (we have two testing environments TS and PY) when someone is modeling something or testing something and they change versions in lower environments they inevitably never get changed back and as such no longer match PD. We need a good way to periodically refresh lower environments version info from PD but still preserve any new versions for new or existing APPLs/UBEs.