Environments

An Environment refers to a dedicated space where an instance of an Application can be deployed. In essence, each environment corresponds to a Namespace in a Kubernetes cluster that encompasses the associated workloads. Moreover, an environment houses any resources on which the workloads of the Application rely.

Each Application can be deployed into one or more environments, each potentially holding different code versions, configurations, or resource sets. You can clone individual Workloads or even entire Environments to different locations. This feature provides a systematic approach to promoting an Application from one environment to another.

Each environment is classified by a distinct type, which can be utilized to manage and access environment sets.

Environment Types #

Every environment is attributed an Environment Type, serving as a classification tool for environments. For example, these types are commonly designated as:

• development: This category encompasses all environments that developers can directly modify.
• staging: Environments under this type are used for conducting verification and quality assurance processes before deploying to a production environment.
• production: This type pertains to environments that are accessed and used by customers.

Environment Types also act as a mechanism to regulate access to environments. For instance, developers may be authorized to manually deploy into development environments, but they might not have the same permission for production environments. This way, the Environment Type acts as a layer of control, promoting both security and efficient workflow management within your IDP.

Cloning Environments #

You can clone an environment to create a new environment with the same configuration. This feature is useful for creating a new environment with the same configuration as an existing environment. For example, you can clone a development environment to create a new staging environment.

By cloning a deployment, you can create a separate Environment where you can test and make changes without affecting the original production environment. You can use Cloning to isolate changes, test updates, parallel developments, and rollback and recovery.

For more information, see Cloning Environments .

Ephemeral Environments #

At its core, an ephemeral Environment is a temporary, on-the-fly instance of an application or system. It’s built to mirror production settings but exists solely for the duration of a specific task, such as testing a feature or bug fix. Once the task is done, the environment is torn down, leaving no traces behind.

Humanitec’s Platform Orchestrator make it possible to not only spin up your container on a new Namespace but also to define which resources to wire the running service to.

The Platform Orchestrator can spin up those Resource, like a database, file storage, or DNS, for you, which is made possible by the power of dynamic configuration management. This means the Platform Orchestrator dynamically creates Applications and infrastructure configurations with every git-push.

Humanitec’s Resource Management and infrastructure orchestration allows you to define in a granular way how those resources are supposed to be created. This can range from making the resource available in-cluster to complex nested resource combinations with IaC formats such as Terraform.

Ephemeral Environments have the following advantages:

• Reduce Resource consumption: No need to maintain long-standing staging or development environments, saving on infrastructure costs.

• Enhance collaboration: Developers, testers, and stakeholders can have their isolated instances to work on or review features without stepping on each other’s toes.

• Boost productivity: Quick setups and teardowns mean faster iterations and reduced wait times.

For information on using ephemeral Environments with your pipeline, see Deploy ephemeral Environments