How to deploy to Standard or Azure environments in Release Management 2013 with Update 3 RC

Roopesh Nair

With Microsoft Release Management 2013 Update 3 RC, you can now use Windows PowerShell or Windows PowerShell Desired State Configuration (DSC) for deploying and managing configuration data. We now support deploying to On-premise environment (Standard) and Azure environments without having to setup Microsoft Deployment Agent.

Prerequisites

PowerShell (PS)

You can use PS scripts to deploy application components to Standard or Azure servers. These scripts can be same as what you might have been already using to deploy to Microsoft Deployment Agent based servers.

RM requires the PS version on target servers to be of version 4.0 or higher. If the Target Server has PS 3.0, upgrade it to PS 4.0.

Desired State Configuration (DSC)

Microsoft supports DSC (Desired State Configuration) as a first-class experience in Windows, RM leverages Windows DSC agent for deployment and configuration.

DSC ships in the box with Windows 8.1 & Windows Server 2012 R2. DSC is also part of Windows Management Framework 4.0 which ships as an optional update and can be installed to Windows Server 2012, Windows Server 2008R2, Windows 7 and Windows 8.

Refer following links to get started with DSC scripts

·       High level concepts

·       Basic introduction

·       Documentation Homepage

1. Managing Releases in Standard Environments using PS/DSC

Follow steps mentions in the blog to setup your on-premise environments as ‘Standard Environment’ in RM

> How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC >

Authoring deployments in Standard environment using PS/DSC

Create a vNext Release Path to represent the stages that your release must go through. Choose the environment and approvers to use for each stage of your release.

Create a new vNext Component and specify how the component gets the files used during the deployment using one of the 3 options.

Create a Release Definition and use the vNext Release path that you have just added.

Add the vNext component that you have created to the Release Definition.

Define the deployment sequence for each of the stages you have defined in the vNext Release Path.

QA Stage:

Production Stage:

For each of the “Deploy to Standard Environment” action, provide the values to the configuration variables.

Details of each of the parameters passed:

ServerName: This is the name of Standard Server i.e the on-premise machine where you want to deploy the application.

UserName/Password:  This is the Account and Password to connect to target Standard Server. This user needs to be a domain user and also member of local Administrator group on Standard Server.

ScriptPath/ConfigurationPath: The relative path for PS/DSC Deploy and Configuration scripts with respect to the package path.

This script will install the component . It can be a native PowerShell script or a DSC script. If DSC, it should contain a “DSC configuration” and a command to create mof for that DSC configuration.

Example: 

FileCopy DSC configuration script with a command to generate *.mof at the end

Note:

• You should not invoke Start-DscConfiguration here. That will be done by RM.

Notice in above script refers to parameters viz., $AllNodes and $Node.DeploymentPath. These are parameter values from an optional configuration file (not to be confused with DSC configuration). Configuration files are useful when you want to use the same script to deploy across different stages/environments with parameterized inputs.

$ConfigData = @{ 

    AllNodes = @( 

         @{ NodeName = $env:COMPUTERNAME;

            DeploymentPath = $env:SystemDrive + "FolderCopyTest"     

          }

    )

}  

Also note that Script/ConfigScript contains reference to $applicationpath. This is the application package path which you would have specified in component package path. Using $applicationpath and relative path you can access any other file in your package from script/config script.

CredSSP: Since RM creates a remote PowerShell connection to Standard Server, CredSSP helps on-premise machine to use the same PowerShell session. CredSSP has to be manually enabled on RM server machine. This value is false by default.

> To enable CredSSP, run the following PowerShell command on Release Management Server with administrator privileges: >

Enable-WSManCredSSP -Role Client -DelegateComputer <Target Machine DNS Name> -Force

UseHTTPS: In case of (https) secure connection this parameter is set as true. Make sure that WinRM is enabled for HTTPS protocol on target server. Default is ‘false’.

SkipCaCheck:  Communication between Release Management Server and the deployment machine will happen using SSL connection if useHTTPS is set to true. The connection established involves certificate verification by Certificate Authority. SkipCaCheck is false by default. It has two values:

>
True: In order to skip the certificate check from happening before establishing the connection SkipCaCheck attribute value must be set to true. >

> False: In order to enable certificate check before establishing the connection the skipCaCheck attribute value must be set to false, and a certificate corresponding to the Hostname to which the deployment machine belongs to must be installed.
>

2. Managing Release in Azure Env using PS/DSC

Follow steps mentions in the blog to setup your Azure in RM

> How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC >

Authoring deployment to Azure environment using PS/DSC

Create a vNext Release Path to represent the stages that your release must go through. Choose the Azure environment and approvers to use for each stage of your release.

Create a new Component and specify how the component gets the files which are uploaded to Azure implicitly during deployment. Storage account information associated with the Azure subscription is used by RM to upload the packages to Azure Blob Service.

Create a Release Definition using the Azure Release path and the Azure component.

Define the deployment sequence for each of the stages you have defined in the Release Path.

QA Stage:

Production Stage:

Release definition based on Azure Environment has actions to Start and Stop the Environment in addition to ‘Deploy to Azure environment’ action

For each of the “Deploy to Standard Environment” action, provide the values to the configuration variables.

Details of each of the parameters passed:

ServerName : This is the name of Azure the VM

UserName/Password:  This is the Account and Password to connect to target Standard Server. This user needs to be a domain user and also member of local Administrator group on Standard Server.

ScriptPath/ConfigurationPath : The relative path for PS/DSC Deploy and Configuration scripts with respect to the package path.

> For details refer to ‘ScriptPath/ConfigurationPath’ section under “Authoring deployments in Standard environment using PS/DSC” >

>   >

UseHTTPS: Not available to set, in case of Azure it defaults to (https) secure connection & this parameter is set as true. Make sure that WinRM is enabled for HTTPS protocol on Azure VM.

SkipCaCheck:  Communication between Release Management Server and the deployment machine will happen using SSL connection if UseHTTPS is set to true. The connection established involves certificate verification by Certificate Authority. SkipCaCheck is false by default for Azure deployments. It has two values:

> True: In order to skip the certificate check from happening before establishing the connection skipCaCheck attribute value must be set to true. >

> False: In order to enable certificate check before establishing the connection the SkipCaCheck attribute value must be set to false, and a certificate corresponding to the HostName to which the deployment machine belongs to must be installed. >

Note: The vNext release pipeline differs from the Deployment Agent-based release pipeline. The vNext release pipeline has the following feature differences:

• vNext Components and Servers are parameters to deployment actions. They can’t be dragged on to the deployment sequence editor as in a Deployer based release authoring experience.

• Extending the target stage, tags-based deployment, agent-less deployments to untrusted domain, custom tools and actions, WinRM deployments using proxy server and manual intervention in deployment sequence features are not supported yet.

• Flow controls viz. ‘Rollback’ & ‘Rollback Always’ are not supported within other flow controls for e.g. Not supported within a Sequence or Parallel controls. Deploy action failures will trigger all previous rollback blocks as well, it is recommended that Rollback scripts are idempotent.

Roopesh Nair Principal Program Manager, Azure DevOps

Follow