Separating the Dev Environment from Prod

I need to separate the Dev environment from the prod environment and move it to a different Server. Has anybody done this before? and if yes what databases would I need to move? and would I need a separate Deployment server?

Thanks

Harry
Oneworld XE
Wintel Platform
Windows 2000 &
SQL 200

No, you don't need a seperate deployment server, nor would I recommend a seperate deployment server. The steps I outline simply move the development databases. Keep in mind that this does not totally detach Development from the other environments since they share the JDE7334 database.

This is an easy move on the SQL platform.

1. Move JDE_Development and JDE_DV7334 to the new SQL Server.
2. Change all pointers to the databases to the new location:
- ODBC
- TNSNAME.SQL (if web)
- JDE.INI references
- JDE7334.SVM7334.F98611 references
- JDE7334.SYS7334.F98611 references
3. Follow the standard instructions to install a JDE Logic server on the new SQL server if desired.

We actually do this at my shop. Remember that if you do install a second deployment server, you are supposed to license the installation separately from PeopleSoft. It's not a good idea to simply get another box and ask for a new SPC.

The original reason we did this was the QA and Production hardware is in Texas but all of the application support folks were in Indiana. Checking in objects and installing packages can take quite a while over a WAN connection, even with a DS-3. The solution was to create one installation of OneWorld and put everything - ERP, point solutions, etc. - in it's own subnet and domain. The other installation of OneWorld was also created and added to it's own domain in the datacenter. This was before my time, so I can *honestly* call it a really great idea.

We have a datasource connection from the dev to qa databases and our consultant hooked OMW up to talk to the second installation. It really works flawlessly 99% of the time. The only issues we've really faced have been network related or Oracle/UNIX problems, not OneWorld.

We have a lot of changes that move up through the environments and to production, and being able to isolate things like ESU's and ASU's to a DEV deployment server is a wonderful thing. I've personally experienced a failed ASU installation from DSI that prevented me from applying any ESU's. Turns out the ASU wasn't properly tested by the good folks at DSI before releasing it to the public. Go figure. If that had happened on our "production" deployment server, and an ESU was ready to be applied to our QA or PD environments that same day...it would have been a scramble to get things done. This also allowed us to upgrade our development environment to 8.9 without the need to use snapshot on the deployment server. Do you really want to trust your backup if it fails? Yikes.

To my knowlege, licensing only becomes an issue if you truly have a totally autonomous second instance.

E1 (OneWorld) is sold as having the ability to scale out by adding database servers, logic servers, deployment servers, java servers and terminal servers in order to support the load.

While autonomy for apply ASU's and ESU's is nice, I would caution against making a second autonomous instance. This product is alread complicated enough. For the ASU, ESU issue, having good backups (to disk and tape) is much easier to implement.

Well, I guess they licensed us separately for no reason. Strange. Thanks for your input.