Once you've added a Service to your Application, you can define Environments where your Service can be deployed. Environments represent one or more of your deployment infrastructures, such as Dev, QA, Stage, Production, etc.

Each infrastructure is defined as an Infrastructure Definition.

In this topic:

Infrastructure Definition Replaces Service Infrastructure

Harness Infrastructure Definitions are replacing Service Infrastructures. With Service Infrastructures, the target infrastructure you defined was tied to a specific Harness Service. It was a one-to-one mapping.

Infrastructure Definitions are not tied to a specific Harness Service, and therefore provide more flexibility and reusability than Service Infrastructures.

To migrate to Infrastructure Definitions, contact support@harness.io.

To learn more:

Add an Environment

The following procedure creates an Environment for a single Service.

To add an environment, do the following:

  1. Click Setup.
  2. Click an Application.
  3. Click Environments.
  4. Click Add Environment. The Environment dialog appears.
  5. Enter a name and description for the Environment. For example, the name DEV with the description, This is the development environment for example.com.
  6. In Environment Type, choose Production or Non-Production.
  7. Click SUBMIT. The Environment Overview appears. Here you can add the Service Infrastructure and overrides to the configurations of the Services that use this Environment.

Add an Infrastructure Definition

Infrastructure Definitions replace Service Infrastructure as the method for defining your target infrastructure. Currently, Infrastructure Definition is behind a feature flag. Contact Harness Support to migrate to Infrastructure Definitions.

See Infrastructure Definitions.

Add a Service Infrastructure

To define your target infrastructure using Harness' legacy Service Infrastructure method, see Service Infrastructures.

For information about how a Service Infrastructure is used in specific deployments, see Deployments Overview.

Override a Service Configuration

For information about how a Service configuration is overwritten in a Kubernetes deployment, see Kubernetes Deployments.

You can configure your Environment to override settings of the Services that use the Environment. For example, a Service might use a specific values.yaml file, but your Environment might need to change the name and namespace of the Deployment object because it is deploying the Service to a QA Environment.

To override a Service configuration, do the following:

  1. In an Application, open an Environment.
  2. Click Add Configuration Overrides. The Service Configuration Override dialog appears.
  3. In Service, click the name of the Service you want to override. Depending on the type of Service you select, the Override Type options will be different. Here is an example of the options available when a Service with Kubernetes type is used.
  4. Click an Override Type option.
  5. Enter the override and click SUBMIT.

24/7 Service Guard

24/7 Service Guard applies Harness Continuous Verification unsupervised machine-learning to detect regressions and anomalies across transactions and events for the service and displays the results in the 24/7 Service Guard dashboard.

For more information, see 24/7 Service Guard.

Troubleshooting Environments

The most common error with environments occurs when an environment's connection to a workflow is changed in such a way as to render it inoperable for a deployment of that workflow. The error is displayed in the Workflows and Continuous Deployment pages:

This error can occur in the following circumstances:

  • A user changes the environment service infrastructure. For example, the user might remove a service infrastructure or change its Deployment Type or Cloud Provider so that the workflow can no longer use the environment to deploy its service(s).
  • A user changes the environment in a workflow. If you open the Workflow dialog and, in Environment, you select a different environment, then a service infrastructure must also be selected in Service Infrastructure.
  • The user clones a workflow to a different application that uses services that cannot deploy to the service infrastructure in that environment.

As a result of these changes, the workflow has no functional service infrastructure specified, and you must select a new service infrastructure for each impacted workflow/phase.

Next Steps

Add a Workflow

How did we do?