An environment is logical groupings of Servers, and generally describes one stage of the development process (development, testing, Q/A, production, staging, etc). But they can also describe other things like a physical location (NYC-DC1, Tokyo-DC1) or even a customer site. You can also Permit or restrict access to servers and Configurations within particular environments to ensure enterprise security and compliance needs.
Otter comes with three, built-in environments that represent a very simple deployment pipeline: Integration, Testing, and Production. You can create, rename, and delete environments as needed.
Environments can have parent environments, which helps with visualization. Privileges and Configuration variables will cascade from parent to child, as expected.
You can associate a server with more than one environment, though it's generally not recommended because it may create unexpected behaviors for other users in your organization.
For example, let's say you configured
APISV to be in both the
Production environments. Someone probably
would expect that a job that targets production servers to target
APISV (which Otter would), but they may not want a staging job to
APISV since it might already be used in production.
Also, both sets of permissions and restrictions will be applied, and if they overlap (one environment grants some things, while the other denies other things), then that will yield unpredictable and ambiguous behavior.