Environment Deployment Triggers, Variables and Security

In the previous step, we briefly discussed environments and queuing policies. In this step, we will look at triggers, variables and security as it relates to environment deployment.

Environment Deployment Triggers

You can configure a continuous deployment trigger in a release definition so that a new release is created automatically whenever a new version of a linked artefact is available. However, you must also configure deployment triggers for each environment in the definition for the new release to be deployed automatically to one or more of these environments.

Deployment triggers are configured for each environment, but the combination of these allows you to orchestrate the overall deployment, such as the sequence in which automated deployments occur across all the environments in a release definition.

For example, you can set up a linear pipeline where a release is deployed first to the Dev environment, then to the QA environment, and finally, if the deployment to QA succeeds, to the Prod environment.

Remember to leave a comment and engage in a discussion with peers. When you are ready, click on Mark as complete and in the next step, you will explore Tasks, Agent Phase Properties, Server Phase.

In the final step of this activity, we will learn about Tasks, Agent Phase Properties, Server Phase.

Alternatively, you can set up a release process in which a build is deployed to a number of QA environments in parallel as soon as it completes, but the release to the Prod environment must always be deployed manually by selecting a successful release and promoting it.

The triggering environment list lets you select more than one environment. This allows you to configure parallel (forked and joined) deployment pipelines where the deployment to an environment occurs only when deployment to all the selected environments succeeds.

Environment Variables

You can use the default variables and define custom variables and variable groups, that enable you to:

• Share values across all of the tasks within one specific environment by using environment variables.

• Share values across all of the environments by using release definition variables.

• Share values across all the release definitions in a project by using variable groups.

• Run your deployments in debug mode to show additional information that can help you resolve issues and failures.

Using variables at the project, release definition, and environment scope helps you to:

• Avoid duplication of values, making it easier to update all occurrences as one operation.

• Store sensitive values in a way that they cannot be seen or changed by users of the release definitions.

Environment Security

Permissions in Release Management define the authorisations that can be granted or denied to users and groups. These permissions can be granted or denied in a hierarchical model at the team project level, for a specific release definition, or for a specific environment in a release definition.

Within this hierarchy, permissions can be inherited from the parent or overridden. To understand the permissions available, and how these are set at the project and release definition level, see Build and release permissions and roles (Security).

For steps on how to add, clone, and use templates; and set triggers, policies, configure variables, and general options, see Where to deploy? Environments in Microsoft Release Management.

In the following step, we will explore Tasks, Agent Phase Properties and Server Phase and you will have the opportunity to take part in a discussion.