All-
I'm looking for guidance on what the best approach would be for maintaining multiple versions of the DevTest software across multiple different "environments".
More specifically, do all the service virtualization components (Enterprise Dashboard, Workstation, Registry, VSE) have to be at the same revision, or can they be different and if they can be different, then how different can they be ?
ORGANIZATIONAL BACKGROUND
In my organization, we have the following service virt architecture::
- The Enterprise Dashboard Service lives on 1 machine.
- The Enterprise Dashboard Database lives on 1 machine.
Teams request a service virtualization environment. Each serv virt environment contains the following ::
- 1 VM that contains the DevTest Workstation
- 1 VM that contains the Registry, VSE, and Portal services.
With this architecture, we are able to quickly provide individual teams with their own serv virt environment to work with.
OUR ISSUE
Now, as we begin to grow and more and more teams begin to receive their own serv virt environments, I'm wondering what would be the best way to go about handling environment upgrades when new versions of the DevTest solution are released?
For instance, currently everything we have is running with DevTest 8.1 (Enterprise Dashboard, Workstations, Registries, VSE, etc). Now that there are 8.2 and 8.3 releases, I'm wondering what would be the best way to go about handling those updates.
Would it be "bad" to let individual teams upgrade their serv virt environments at their own leisure? This seems like it would probably be the best approach, but I'm not sure how backwards compatibility will affect this. For example, if we updated the Enterprise Dashboard machine to DevTest 8.3, will that break its interoperability with serv virt environments still running 8.1?
Ideally, we would just upgrade the Enterprise Dashboard every time a new DevTest version is released, and then teams could just update their individual environments if they wanted to, but is that realistic/wise?
Hopefully someone else has an organization with a similar architecture and can offer up some advice on how to handle this.
Thank you for your time,
Jeff