Multiple Instances for Developers

Can anyone share their experience with having multiple instances of JDE running and how development was performed? We will eventually have as many as 10-15 separate instances of 8.12 running. Each with their own deployment server, enterprise server, and JAS box. Essentially each company has their own standalone setup. The question is, we have developers that will need to develop on all the different instances and I am trying to determine the best path for having multiple Fat clients to do development work. Can I use snapshot to go between the different instances? Will VMs or Virtual PC work? How about remote development workstations? Looking to see if anyone is in the same situation and what they have done. Thanks...

I understand the need for multiple Enterprise and JAS servers, but why do you have multiple Deployment Servers? Is each company geographically separated, and has their own hardware? Or is everything under your central control?

To answer your questions, you could use SNAPSHOT to switch between Development environments. Configuring VMs or using Virtual PC would work too, though they would take up a lot more space than using SNAPSHOT.

SNAPSHOT Pro: uses less disk space and memory than configuring a virtual machine
SNAPSHOT Con: notoriously easy to get confused and mess up the configuration; only one instance can be running at one time

Virtual Machine Pro: each instance is completely separate; you could run multiple sessions and be working on more than one at a time
Virtual Machine Con: need more memory to run a VM; need more disk space to hold a full VM instance; extra licensing cost of OS

If you have the servers to run all the different VMs, that's great. Another thing you could do, since you've brough up Virtual PC, is to have each developer host the instances on their own PCs, and run them with Virtual PC or VMWare Player. The answer to that depends on how much control you want over each VM, and whether you want to allow the developers to mess with the VM's virtual hardware configuration.

I have done it both ways. The quickest way was for me to create the VMs in the free VMWare Server, create a base VM, clone the VM as needed, change the PC name and SID info, and give the developer a copy of the VM files along with VMWare Player (also free) to run whereever they needed to.

Hi,

Wow! 10 to 15 independent instances with their own
Deployment, Enterprise and JAS... that's gonna be tough
for your developers and for yourself as a CNC, I hope
you don't need to sleep too much!

Given that every JDE installation will have its own
Deployment, you can't have them all active at the
same time on a given PC, you'll need to use either

1. Snapshot tool to switch from one environment to
the other on the same PC. There's a restriction on
that : what if they're on different JDE releases
(let's say 8.10 and 8.12) and they need different
C++ compilers, WAS Express environment or DB clients?

OR

2. A better solution : to provide each developer
with a VMWare machine running several virtual PCs
as Fat Clients (one per JDE installation they will touch).

RDP and Citrix are not appropiate development environments,
they're quite unstable, specially when you have to debug.

Hope my comments were useful,

Sebastian

or have them using Virtual PCs (VMWare or any other
similar product), each PC

Thanks for the thoughts so far guys. The reason for so many instances/deployment servers is that each company has to operate independently of the other. I can't have one companies equipment issues affect another. So yes, it will be quite a scene once they are all up and running. I have heard rumors that using Virtual Machines is unacceptable for heavy development, but I am willing to give it a try as I think that may be the best way to go.

[ QUOTE ]
We will eventually have as many as 10-15 separate instances of 8.12 running. Each with their own deployment server, enterprise server, and JAS box. Essentially each company has their own standalone setup.

[/ QUOTE ]

Steve,

I would architect that a little differently. I can see the need for seperating business data for different segments of the business, either along product line or geography. But instead of treating each instance as an island, with your developers paddeling in between on their canoes, I would try to centralize the hardware and the application code. Have one big high end enterprise server. Have your 15 different sets of business data. Use OCM to create multiple PD environments. Keep the application code the same across the instances, but only allow users to log in to a specific PD environment. I would put the webservers on VM-ware. Especially if I had users in multiple timezones. That would keep the VM-ware humming along around the clock, and be less physical boxes to maintain. In a combo environment, your developers won't be doing the same work over and over again when they support the different business units. The CNCs will do less packages, install less service packs, etc. If you go that route, you can gain a tremendous amount of econmies of scale. Food for thought..

Gregg

[ QUOTE ]
The reason for so many instances/deployment servers is that each company has to operate independently of the other. I can't have one companies equipment issues affect another.

[/ QUOTE ]

That one's easy to fix - hire more competent infrastructure guys. If you have that many issues that you need to isolate hardware and put a tremendous overhead on your developers and CNCs, because the underlying equipment isn't reliable, than your infrastructure guys are doing a crummy job.

Gregg,

I understand your point, but the reason that the hardware has to be separate is for different reasons. The corporate headquarters of the company is essentially a holding company for the 15 other companies. Each of the independent companies, although owned by corporate, has a right to go out and find IT services else where if they want. So here at corporate, we are essentially run like a consultant shop. The other companies "hire" us to do their IT services, and if we don't perform, they can go elsewhere. It is for this reason, that each company gets their own instance, own 400, their own hardware. We treat them separately just as a consulting company would not mix hardware if they were hosting hardware for multiple companies. In other words, I can't say, "Hey company A, I can't build a package for you because the deployment server for company B is down for maintenance right now."

Steve,

has anyone approached it from this angle, approach two or three of the businesses and ask them if they want to pool their resources on a joint system like I described. Since I'm sure your time is being billed back to the business units, the ones that voluntarily join together can save themselves a ton of money on reduced hardware, software, licenses, labor, and reduced overhead. If each company is seperate, there is probably a lot of excess capacity. Combining businesses on the same hardware will allow the parent company to run more leanly.

I'm Sorry...