Create self signed certificate on Windows

From this blog post:

https://blogs.msdn.microsoft.com/benjaminperkins/2014/05/05/make-your-own-ssl-certificate-for-testing-and-learning/

Ensure Powershell version 5 is installed.

Run a Powershell command as administrator (ensure that path c:\temp exists first)

c:\> $cert = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname *.mydomain.co.uk
c:\> $pwd = ConvertTo-SecureString -String ‘mypassword’ -Force -AsPlainText
c:\> $path = 'cert:\localMachine\my\' + $cert.thumbprint
c:\> Export-PfxCertificate -cert $path -FilePath c:\temp\cert.pfx -Password $pwd

The certificate can then be applied to IIS web site locally.

VSTS Web Deployment to different environments end to end using parameters and transforms.

This post shows how to use web.config transformations and parameters in Release Management in Visual Studio Team Services.

The VSTS interface and tasks are constantly evolving, but this is correct as of 10th November 2017.

Deploy a web site to different environments (eg QA, Live) using VSTS using web.config transformations and parameters.

Assumptions:

  • Solution contains a web application in Visual Studio 2017
  • Visual Studio Team Services for source control, build and release management
  • Deploying to Azure Virtual Machine

 

Step 1 Add Configuration to the Solution

Web.config transforms

Right-click the solution and choose Configuration Manager.  Add a new configuration named “QA”.

Then right-click the web.config & select “Add Config Transform”.  This will create a file called “web.QA.config” nested under web.config.

Note that the nested files can causes issues (see https://github.com/Microsoft/vsts-tasks/issues/3507) so to remove the nesting, edit the project’s .csproj file and locate the section relating to web.QA.config …

 <Content Include="Web.QA.config">
   <DependentUpon>Web.config</DependentUpon>
   <CopyToOutputDirectory>Always</CopyToOutputDirectory>
 </Content>

Then remove the  <DependentUpon> node – the config section should now look like this:

 <Content Include="Web.QA.config">
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
 </Content>

 

Parameter file

Create a Parameters.xml file.

(A Visual Studio extension can be used to generate the Parameters.xml file for example https://github.com/rfennell/ParametersXmlAddin)

In the parameters.xml file, if you want a value to be set for a particular environment, edit the “defaultvalue” to something like “#{myTestParam}#”.  So in this case the parameter name myTestParam is enclosed within #{ and }#.  This pattern is used in the Release pipeline.

Step 2 Setting up the Build

Assuming the solution is in source control, create a build definition in Visual Studio Team Services (see elsewhere for how to do this).

This method uses a “build once,  deploy many” technique – it will build the solution using the general “release” configuration, ie. NOT the new QA configuration.

In the “Build Solution” task set the MSBuild Arguments as follows:

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" /p:AutoParameterizationWebConfigConnectionStrings=False /p:TransformWebConfigEnabled=false

Note that TransformWebConfigEnabled is set to false – the transforms will be done in the Release.

Queue a build and check that the correct artifacts are created.  You should get a zip file for the web site and a “SetParameters.xml” file which will be named YourWebApp.SetParameters.xml:

build-artifacts-params

 

Step 3 Setting up the Release

This assumes a deployment group has been set up (see elsewhere for how to do this).  The target virtual machine is part of the deployment group.

Create a release definition using the artifacts from the build:

release
The release pipeline

Create an environment called “QA” – this is important – it must match the name of the configuration in the Solution (but it is not case sensitive).

In the QA deployment process, create a “Deployment group phase” and add a task to replace tokens and a task to deploy IIS Web App:

releaseQA

Replace Tokens task:

(Note that this task has been installed from the market place, https://github.com/qetza/vsts-replacetokens-task#readme)

  • Set the Target files to **\*.SetParameters.xml
  • Under the Advanced section, set the Token prefix and suffix (in this example we have a prefix of “#{” and suffix of “}#” without the quotes)

IIS Web App Deploy task:

  • In File Transforms & Variable Substitution Options, tick “XML transformation”.  [By ticking the release process will look for a web.config transform file called web.EnvironmentName.config, in this case web.QA.config.]  Note that if there is a file called web.Release.config then that transform will also be applied.
  • In Advanced Deployment Options, enter the path to the “SetParameters.xml” file in the artifacts folder (it will be named YourWebApp.SetParameters.xml)

Setting Environment Variables for the Release

While editing the release definition, click on the Variables tab and enter variables for the QA scope.  Note that parameter names are case sensitive.

For example, if your parameters.xml contains configuration for an appSetting called MyTestParam like this:

<parameter name="MyTestParam" defaultvalue="#{MyTestParam}#" description="" tags="">
 <parameterentry kind="XmlFile" match="/configuration/appSettings/add[@key='MyTestParam']/@value" scope="\\web.config$" />
</parameter>

Then in VSTS Release definition the variable should be set up with:

Name: MyTestParam

Value: Whatever value you want

Scope: QA

Note that the Name is a case sensitive match to the value of defaultvalue within #{}# in the parameters.xml file.

Adding a New Environment

To create a “Live” environment would involve the following steps:

  • In Visual Studio, create a new configuration called “Live” for your solution, create the web.live.config transform & ensure to remove the dependentUpon node in the .csproj file.
  • In VSTS,
    • edit the release definition and clone the QA environment and rename this copy to “Live” – important as the name must match the new configuration in your solution.
    • Create new values for the release variables for “Live” scope