What is an "environment" in Otter?
  • 18 Feb 2022
  • 1 Minute to read
  • Dark
    Light
  • PDF

What is an "environment" in Otter?

  • Dark
    Light
  • PDF

An environment is a logical grouping 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.

  • Server Targeting; when running a job, you can specify environments as well as server roles so that you can easily target a range of servers at once, allowing you to scalably provision and configure servers
  • Restrict Access; you can also Permit or restrict access to environments to allow for self-service; for example, you could permit “QA Users” to run certain jobs against the Testing environment, while restricting them from the Production environment.

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 and Drift

Although you can't define a Configuration plan for an environment, an environment can still be drifted if any of the servers within it are in a Configuration Drift.

Nested Environments

Environments can have parent environments, which helps with visualization. Privileges and Configuration Variables will cascade from parent to child.

Multiple Environments per Server

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 APISV1 to be in both the Staging and Production environments. Someone probably would expect that a job that targets production servers to target APISV1 (which Otter would), but they may not want a staging job to target APISV1 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.

In addition, when a server is in multiple environments, then there can be no single environment in context when executing OtterScript against this server. This means that the variable function $EnvironmentName will return empty, and variables cannot be resolved. Instead, multiple roles are recommended.


Was this article helpful?