• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

DEV - The Forgotten Environment - UDCs VERS Data

johndanter

Legendary Poster
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

Reputable Poster
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

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

Chan
 

Larry_Jones

Legendary Poster
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.
 

jdelisths

Reputable Poster
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

Legendary Poster
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

Well Known Member
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

Legendary Poster
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

Legendary Poster
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

Legendary Poster
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

Legendary Poster
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.
 
Top