As you promote your application through test, UAT, staging and production, there are going to be differences in:

• Database connection strings
• Application settings
• Web service URLs
• Many other parameters

To make it easy to support different environments without hard-coding these configuration values, the Deployment Manager web interface allows you to create variables.

These variables are used during your application deployment. For example, variables you define will be automatically substituted into XML configuration files, and made available to your PowerShell scripts. This allows you to create applications and deployment scripts that are agnostic of the target environment.

Contents

Scoping

A variable can be 'scoped' to zero or one of each of the following:

• An environment (most common)
• A specific target
• A specific package

For example, suppose these variables exist:

During deployment, Deployment Manager will try to select the most specifically scoped variable that applies. For example, when deploying to Production, the LogLevel property would be Warn. But to any other environment, it would fall back to the less-specific variable and have a value of Info instead.

Predefined variables

Deployment Manager automatically makes a number of common useful variables available during each deployment. All predefined variables have a RedGate prefix. The available predefined variables are:

The following additional variables don't have a default value, but can be set by you to override Deployment Manager behavior:

IIS website variables

You can use the following variables when deploying an IIS website:

Database variables

The following variables are set when you add a SQL Server to an environment through the web interface. You can use the variable names below to reference them in other steps:

The following variables are set when you configure a database package step through the web interface. You can use the variable names below to reference them in other steps:

Database deployment options

Database deployment options are variables that control how Deployment manager deploys databases, for example by excluding certain database objects like users or indexes. The variables have the prefix, RedGateDatabaseOptions and can be set to true or false.

For more information about database deployment options, including a list of variables and their descriptions, see Database deployment options.

Referencing variables

Referencing variables within the same scope

To dynamically update a value on deployment, you can reference a variable using $(variable) notation. The variable is evaluated on deployment.

You can create custom variables and reference them, or you can reference built-in variables, such as the predefined variables, database variables and IIS website variables.

This will reference variables which are inside your current scope. To reference variables outside the current scope but inside the same project, see Referencing variables from a different step or target.

Examples

• When adding a database package step, the Database name is set to $(RedGatePackageName) by default. The database name will evaluate to the package name on deployment.
• You can specify a value for your package directory path that includes the package version number. This means on every deployment, the package will be extracted in a new folder with the package version number as its name.

Syntax

To reference a variable, specify $(variable)

To include the literal characters $( in a variable without referencing another variable, specify $$(

This is interpreted as a literal $( on deployment.

Syntax Examples

• To set the package directory path so packages are extracted in a folder for each version, set the variable RedGatePackageDirectoryPath to:

C:\MyApp\$(RedGatePackageVersion)

• By default, the database name when creating a database step is set to:
  
  so the name for the database is the same as the package name.

Referencing variables from a different step or target

To reference a variable from a different step or target, you can use :: notation inside the $(variable) notation. The step and target referenced must be in the same project.

Syntax

To reference a variable in a different step, specify $(step::variable)

To reference a variable in a different target, specify $(step::target::variable), where target is the literal string target rather than its name.

Example use case

We're deploying a web application that incorporates a website deployment step, called WidgetWebsite, and a database deployment step, called WidgetDatabase. The website needs to access the database, so the website step needs to use the user name and password from the database step.

In the website step, we create two custom variables:

The WidgetWebsite deployment step can now pass these values to the website so it can access the database. The database deployments most only contain one target per environment or the deployment will fail.