How to create a new environment

Within your repository, select Settings and then Environments. Any environments created will be listed here. To create a new environment, select the New environment button.

You are then presented with the Name field where you can provide your environment any name you like. Once you have entered a name, select the Configure environment button.

Configuring a environment

If you have created a new environment, you will be redirected immediately to the configuration page. If its an existing environment you want to configure, you can select the environment name in the list of environments where you will then be presented with the environments configurations.

Deployment protection rules

Environments are commonly used for deployments. An environment can be customised to protect the deployment using the following rules:

Required reviewers - This will prevent a deployment of a workflow to trigger automatically. You can specify the user or teams who can approve a workflow to run within the Add up to… input field. You can also enable Prevent self-review, which prevents the user who triggered the workflow to approve their own run.

Wait timer - If a workflow is triggered without or with a reviewers approval, the wait timer will wait to start the workflow until the specified amount of time has passed. This can be used if you want a buffer window where someone can stop the workflow if they didn’t want it to trigger, or to wait a period of time to allow for other jobs outside of the workflow to complete.

Allow administrators to bypass configured protection rules - This options allows an administrator of the repository to bypass the configured protection rules above. This can be beneficial if a critical item needs implementing without approvals or wait timers, but can also be abused by administrators to bypass processes. I would recommend turning this off if you have administrators set that should follow all protection rules practices.

Deployment branches and tags protection

Deployment branches and tags configuration can be used to restrict what branches or tags can be used to run on the environment deployment. This can be useful to restrict based on the following examples:

• Main branch to deploy to production environment only

• Tags starting with beta can only run on the beta-users environment

The restrictions are set out as follows:

No restriction - do not apply any restrictions on this environment, allowing for any branch or tag to run on the environment

Protected branches only - branches that are secured by a protection rule can run on the environment

Selected branches and tags - Using naming patterns, you can specify conventions used by your branches or tags that can then be allowed to rune on the environment.

Environment secrets and variables

Finally, you can use Environment secrets and Environment variables to store values that only your environment has access to. This can be very useful to split up values that are not shared across different environments, or should not be accessible by non-environment workflows.

Environment secrets - these are secured values that are not visible once you add it. It is a good idea to store these values externally if you need access to them in the future as you cannot easily access these once they are inputted into the environment secrets store.

Environment variables - these values are non-sensitive values that are visible in clear text. These should not contain any passwords or secrets as these will be visible in the workflow run logs and to any user who has access to the environments configurations.

Once you are finished configuring the environments, you can click save and now are usable in your workflow by specifying the environment when configuring a stage.