I am sure this topic must have been discussed before but I did not come across a good article and can certainly use help.
I created few views that I wanted to move from my sandbox project to Dev project which was a restored version of production system.
Many of the object in my views were all broken up. I had to fix all these before I could try on production sever.
Playing for fun is one thing but messing up production system is at whole new level.
I would sincerely appreciate collective best practices to streamline these moves.
Consider running one more trial gateway as your "staging" or "QA" gateway. Load a gateway backup from Production into it. Make sure all IP addresses and host names used in Production point to a suitable non-production alternate (or go nowhere).
Add your new resources to that gateway, keeping track of all changes you make to get the proper result. Then repeat in production at a suitable time.
Consider also making your Dev environment a close replica of Production, with live connections to alternate databases (using the same IP/host as production) and one or more live connections to simulated PLCs (again, same IP/host as production). Such that dropping a production gateway backup into Dev "just works" without disturbing production. Then resources can be moved directly from Dev to Production.
What would you suggest for a simulated PLC? Theoretically at the bare minimum it should just be something that responds to OPC UA requests for data, but at the next level up it should mimic the responses of the real hardware.
For Rockwell, I recommend their emulators or my EtherNet/IP module. For anything involving Modbus, I recommend my Advanced Modbus Module's server driver.
The above, when given IP addresses (or hostnames) matching the production environment, respond to network traffic from your relocated gateway backup just like the real devices. (You don't have to use a separate Ignition gateway just for the simulators, but it has some advantages.)
For OPC UA connections, you may need to extract certs from your real devices to install in your simulation server(s), but there are a number of open source OPC UA stacks you can work with.
Other brands and their native protocols are much more trouble--there's no obviously easy simulation tools. If you find something that will respond to IA's drivers as if the real thing, please let us all know. This is one of the reasons I have real PLCs in my lab environment--to respond to client configurations in place of the production systems.
That last is the point: A production backup should be able to be dropped into a dev environment and start up with actual device connections to simulators. Or to real PLCs loaded with the expected content. Possibly not all of the connections would work in dev, but the ones needed for the task at hand.
For my modules, when placed in a gateway dedicated to simulation, the simulation side logic can be emulated with jython timer event scripts. It isn't practical to emulate everything, in most cases, but having logic that handles heartbeats and handshakes is reasonable.