I would recommend to install it; it doesn't cost you anything and you will only use it rarely.
I would also recommend to go for a three server setup, i.e. database, production, and development servers. All can be virtual, and the dev server doesn't require lots of resources. A separate dev server becomes important when runing ISM upgrades, which will not only replace the binaries on your server. In most cases the upgrade needs to make changes to your db as well, and if this fails or your customizations run into problems later, you'll become quite busy to restore both database and server to their former setup. Your 150 staff members (if they are all supposed to work with ISM) will patiently wait for you.
Coming back to the OpsConsole: you will use it to set up your Staging (Dev) and UAT (Test) tenant, by simply pressing the Push button, which basically copies the databases across. You can use OpsConsole to move changes from Dev to Test to Prod, but its easier (imho) to use package export/import for that. You only need OpsConsole to rebuild Dev or Test from time to time.
So I'm most likely confused on the meaning of 'tenant'. I thought I would have one tenant, namely http://company.com with three different landscapes
I also thought the install is where those tenants/landscapes are created; production first, then re-run the install and create the uat & dev landscapes.
During the first install, I created the OpsConsole on my production server. Are you saying to use that to create the other two tenants/landscapes?
First of all, it's not recommended to install all three landscapes (DEV, UAT, PROD) on one server as Bernd mentioned.
Instead, you should rather use different servers and URLs to host your tenant's landscape instances, e.g.:
You can still do it and move to another server later on, though.
I would definitely recommend using the Operations Console with development projects and package migration to avoid unauthorized or accidental changes in UAT and PROD (metadata is automatically locked and only unlocked by the OpsConsole).
It takes a while to get used to it but once you do it's straight forward and much better than just exporting and importing packages.
Simple example: I have to extend a knowledge workflow to also notify the article's OwnerTeam once it gets published
1) Do you changes in DEV as required:
- create a development project and choose it to track your changes
- create a development package
- do your changes, e.g. extend your workflow, publish as new version and/or modify quick actions. Test them as needed.
- check your transaction sets and assign them to your development package:
2) push to UAT:
3) close the development package and push it to PROD (same as 2)
I don't see a reason not to use this feature. :-)
The OpsConsole should be installed on the development server and will look like this after being configured:
Thank you for the help. I'm installing a second server to hold both dev and uat; I'll install the ops console there. Your explanation has been helpful.