Embracing Continuous Delivery With Release Management for Visual Studio 2013

8/10/2019 Embracing Continuous Delivery With Release Management for Visual Studio 2013

1/76

Hands-On Lab

Embracing Continuous Delivery with ReleaseManagement for Visual Studio 2013

Lab version: 12.0.30723.00 Update 3

Last updated: 9/10/2014


2/76

CONTENTS

OVERVIEW ................................................................................................................................................... 3

EXERCISE 1: RELEASE MANAGEMENT OVERVIEW .............................................................................. 4

EXERCISE 2: CONFIGURING RELEASE MANAGEMENT ...................................................................... 11

EXERCISE 3: DEFINING A RELEASE PATH AND TEMPLATE .............................................................. 19

EXERCISE 4: RELEASE AUTOMATION EXAMPLE ................................................................................ 30

EXERCISE 5: RELEASE MANAGEMENT SUPPORT FOR AZURE AND DSC (OPTIONAL) ................ 52


3/76

Overview

In this lab, you will learn about Release Management for Visual Studio 2013 and its suite of release and

deployment tools that automate the deployment of applications across the desktop, server, and thecloud. Release Management for Visual Studio 2013 helps development and operations teams integrate

with Team Foundation Server 2013 to configure and automate complex deployments of their automated

builds to target environments more easily. Development teams can also model their release processes

and track approvals, sign-offs, and visualize their release status.

Note: If you want to skip the overview and configuration exercises and go straight to a live

demonstration in action, you can start with Exercise 4. If you are new to Release Management,

however, it is recommended that you at least read the first few exercises for some background

information.

Prerequisites

In order to complete this lab you will need the Visual Studio 2013 virtual machine provided by Microsoft.

For more information on acquiring and using this virtual machine, please seethis blog post.

About the Fabrikam Fiber Scenario

This set of hands-on-labs uses a fictional company, Fabrikam Fiber, as a backdrop to the scenarios you

are learning about. Fabrikam Fiber provides cable television and related services to the United States.

They are growing rapidly and have embraced Windows Azure to scale their customer-facing web site

directly to end-users to allow them to self-service tickets and track technicians. They also use an on-

premises ASP.NET MVC application for their customer service representatives to administer customer

orders.

In this set of hands-on labs, you will take part in a number of scenarios that involve the development

and testing team at Fabrikam Fiber. The team, which consists of 8-10 people, has decided to use Visual

Studio application lifecycle management tools to manage their source code, run their builds, test their

web sites, and plan and track the project.

Change log

For Update 3:

Added optional exercise demonstrating release to Azure using DSC

Changed Release Management Deployer references to Microsoft Deployment Agent
http://aka.ms/VS13ALMVMhttp://aka.ms/VS13ALMVMhttp://aka.ms/VS13ALMVMhttp://aka.ms/VS13ALMVM


4/76

Updated manual release to trigger from Configure Apps | Release Templates instead of Releases

tab in Release Management Client.

Added note to end of Ex. 3 regarding tagging support

Screenshot updates as necessary, other minor edits

Exercises

This hands-on lab includes the following exercises:

1.

Release Management Overview

2.

Configuring Release Management

3.

Defining a Release Path and Template

4.

Release Automation Example5.

(optional) Release Management Support for Azure and DSC

Estimated time to complete this lab: 60 minutes.

Exercise 1: Release Management

Overview

In this exercise, you will learn about the Release Management product and how it interfaces with Team

Foundation Server to provide an automated deployment solution. You will also see what an example

release workflow looks like from the Release Management web client.

1.

Log in as Brian Keller (VSALM\Brian). All user passwords are P2ssw0rd.

2.

The goal of Release Managements architecture is to provide a mechanism where application

components can be deployed automatically to various target servers in different environments.

The components may require different configurations on the various servers but we still want to

deploy the same package to all of them. Another key goal is to keep all the configuration

information centralized and manage the deployments as part of a business driven release

workflow that involves multiple roles in the organization.

3.

In order to accomplish these goals, Release Management is based on four main components.


5/76

Figure 1

Release Management components

Note: Starting with Update 3, there is now the option of deploying to environments that

support DSC (Desired State Configuration). Therefore in this case, without a deployment agent

running on the target servers, the release operation would push deployment bits to the target

servers.

Release Management Server.The server component is the heart of the solution and consists of

the database, the workflow controller, and a dispatcher that synchronizes activities with the

target servers.

Release Management Client.The client comes in two flavors, a Windows Presentation

Foundation (WPF) based client that exposes all the functionalities of the application and a web-

client designed for testers, user acceptance approvers and managers.

Microsoft Deployment Agent.The deployment agent is a service that is installed on the target

servers where the application components need to be deployed. It is important to note that the

Release Management Server does not require access to the target servers as all operations are

based on a pull mechanism from the deployment agent.

Deployment Tools.The Release Management solution provides various installation tools that

assist different deployment scenarios such as uninstalling/installing components, deploying

reports to Microsoft SQL Reporting Services, and moving files to specific locations.


6/76

Note:This self-contained virtual machine has all Release Management components installed

on it for demonstration purposes, including the deployment service.

4.

It is important to note that the Release Manage product, after having been acquired by

Microsoft, will continue to be transformed and integrated into existing tools. The release

management authoring components will be included in Visual Studio Test Professional, Visual

Studio Premium, and Visual Studio Ultimate. Everything needed to participate in a release

process will be included in the Team Foundation Server CAL. Server components will be

integrated into Team Foundation Server 2013. The deployment agents (which are required for

each node you deploy on) will continue to be licensed separately.

5.

The basic mechanism used in Release Management is to have the users interact with the server

through the appropriate client where new release requests or stage approvals will trigger

deployment requests to the next stage in the release path. Launch the Release Management

web application by navigating tohttp://vsalm:1000/ReleaseManagement. Note that we do notcurrently have any pending approval requests.

Figure 2

Release Management web application

6.

Select the Previously Approvedlink and note that there was a release triggered by a build of

the Fabrikam Call Center.
http://vsalm:1000/http://vsalm:1000/http://vsalm:1000/


7/76

Figure 3

Viewing previous approvals

7.

Select the link displaying the number of deployed components (just underneath the name Brian

Keller).

Figure 4

Location of components link

8.

This shows us the components that were deployed during each stage of the release path. In this

particular case, it was just a specific build of a web site.

Figure 5

Viewing components deployed

9.

Press the Escapekey to close the dialog window.


8/76

10.

Note that we can see at a glance that the deployment is currently in the production stage.

Select the stageslink to view the historical workflow and approvals that occurred to get to that

point.

Figure 6

Location of stages link

11.

This dialog window shows the workflow steps and results that occurred in the Prod

(production) stage. It was manually accepted from the previous stage by Brian Keller,automatically installed to the deployment environment, and finally validated by Brian once

again.

Figure 7

Prod stage historical workflow

12.

Select the Previous Stagelink.


9/76

Figure 8

Location of Previous Stage link

13.

This stage was setup to be for QA. Note that this stage has more workflow automation in place

it automatically accepts, installs, and validates the application and then waits for a QA team

member to approve it.

Figure 9


10/76

QA stage historical workflow

Note: The setup used for the stages seen in this lab are for demonstration purposes only. In

normal scenarios, the QA stage would not automate the acceptance step. It would usually be

setup for an owner of that stage to decide when to deploy a new version.

14.

Select the Previous Stagelink to view the Dev(development) stage history. There is quite a

bit of automation going on here as well, but note that manual approval was necessary in order

for transition to the QA stage. This final approver simply indicates that the current version

meets all needed quality gates and should be made available to the next stage (QA in this case).

We will see how all of this is configured later on in this lab, but for now just remember that the

flow through the different stages (Dev -> QA -> Prod) is what we refer to as the release path.

Figure 10

Dev stage historical workflow

15.

Press the Escapekey to close the dialog window.

16.

The paths are composed on the various servers grouped in environments on which the testing

for the stage is performed. Once an application needs to be deployed to a new environment,

the server will queue deployment requests to all the required target servers for each

component of the application. This allows an atomic deployment of all the components.


11/76

17.

The Microsoft Deployment Agent running on each target server monitors the Release

Management server continually (at a configurable interval) and will pick the installation

requests for the one or more components it needs to install locally.

18.

The deployment agent will then find and download the release package, provided by the

Release Management Server that calculates the location using the TFS API - if built by TFS - or

using a predefined UNC path - if not.

19.

Finally, the deployment agent downloads any additional executable (batch file, PowerShell

script, .exe) to be ran as part of the installation. These are additional deployment activities

beyond the installation itself; creating test data or triggering automated tests are common

scenarios here.

Exercise 2: Configuring Release

Management

In this exercise, you will learn about the main configuration points that are needed to connect Release

Management to Team Foundation Server, various settings for Release Management including those that

apply to the deployment agent services, the configuration of groups and users, and finally the

configuration of servers and environments.

1.

Launch the Release Management clientfrom the taskbar.

Figure 11

Release Management client splash screen


12/76

2.

By default, Release Management will load the Traffic Overviewtab which shows deployments

moving through all release paths and stages. This shows us that the Fabrikam Call Center

application has already had a deployment go through each stage of deployment without any

failures.

Figure 12

Traffic overview

3.

Lets take a quick look at some of the main configuration tasks that need to be addressed when

installing and configuring Release Management. Select the Administrationtab followed by the

Manage TFS link.

Figure 13

TFS connection configuration

4.

Double-clickon the TFS connection that has already been setup.

Figure 14

Loading configuration for TFS connection


13/76

5.

This connection was setup in the virtual machine ahead of time, but it is important to note that

the user account used by Release Management needs to have the Make requests on behalf of

others permission within TFS.

Figure 15

Configuring account to connect to TFS

6.

Other important settings can be configured in Administration | Settings. The SystemSystem

Settingstab (default) shows various timeouts, version information, SMTP configuration, and

license information. These settings are all defaults that were set during the creation of this

virtual machine.

Figure 16

System settings

7.

Select the Deployer Settingstab to view the configuration options for all deployer services. For

example, you can set how often you want the deployment agent to poll the Release

Management server for packages to deploy.


14/76

Figure 17

Deployer settings

8.

Lets take a quick look at the setup of users and groups for Release Management. Navigate to

Administration | Manage Users.

Figure 18

User configuration

9. Double-clickon the Brian Kelleruser.

Figure 19

Viewing user configuration details

10.

The Brian Kelleruser is associated with the windows account VSALM\Brian, is designated a

Release Manager, and is an active member of a few different teams.


15/76

Figure 20

Viewing user configuration details

11.

Navigate to Administration | Manage Groupsto take a quick look at how groups can be setup.

Figure 21

Group configuration

12.

Note that you can create new groups from scratch or you can import them from Active

Directory or Team Foundation Server. Groups that are imported from AD or TFS in this way are

linked by default, and will therefore remain synchronized.

Figure 22

Importing groups from AD and TFS

Note: Synchronization is manual (using the Refreshbutton) unless the setting AD/TFS-Based

Group Refresh Interval is setup to something other than 0 minutes (which is the default).


16/76

13.Double-clickon the QA Team.

Figure 23

Viewing group details

14.

The Memberstab shows the individual users that are part of the QA Team. You can add moreusers here if desired (since the group is not linked to AD or TFS).

Figure 24

Viewing group members

15.

Select the Securitytab.

Figure 25

Location of Security tab

16.

The Securitytab allows you to specify what Release Management permissions that the group

has. For the purposes of this virtual machine, the team members have full control.


17/76

Figure 26

Group security settings

17.

Navigate to Administration | Manage Pick Listsand take note of the Stage Typesdefined here.

The stage type names defined here are completely arbitrary, and therefore can be molded to fit

your desired release strategy.

Figure 27

Configuring stage types

18.

Servers to be used for deployment must have the Microsoft Deployment Agentservice

installed and configured to connect to the Release Management Server over HTTP or HTTPS. In

addition, these servers must be explicitly added to Release Management Server. Navigate to

Configure Paths | Serversand note that the deployment agent service has already been setup

and configured for this virtual machine.

Figure 28

Configuring servers


18/76

Note: Although we wont do so here, the recommended way to add additional deployment

servers is to select the drop-down arrow next to the Newbutton and then select Scan for

New.

19.

Double-clickon the VSALMserver.

Figure 29

Configuring servers

20.

There are many options shown here for the selected deployment server, but the general

takeaway is that you want to configure servers that you add to be uniquely identifiable so that

Release Management Sever can target them. It is possible to used cloned servers, configure the

address type to be a gateway, and to have the server use HTTP(S) to grab the deployment bits

from the drop location (if it a UNC path is not an option).

Figure 30

Configuring servers

21.

Navigate to Configure Paths | Environments.


19/76

Figure 31

Viewing environment configuration

22.

Servers are grouped into environments so that servers are decoupled from release path

definitions and so that various stages of the release path can be restricted to certain

environments. Double-clickon the first environment named Int-Dev.

Figure 32


23.

As the description states, this environment is meant to define the group of servers used for a

development environment. If you wanted to restrict the use of this environment to specific

stages, you could do so in the Stage Type Securitytab.

Figure 33


Exercise 3: Defining a Release Path and

Template


20/76

In this exercise, you will learn how a release path and release template are created and configured. You

will also see how to use the actions and tools provided to deploy an application to the correct

environment.

1.

Now lets look at a release path definition. Navigate to Configure Paths | Release Pathsand

double-clickon the Fabrikam Call Centerrelease path.

Figure 34

Viewing release path

2.

This release path defines a three-stage path through Dev -> QA -> Prod using the selected

environments. Most steps for the first two stages are automated, so the assigned user or group

does not intervene. Both the Dev and QA stages required approval before the next stage could

begin.

Figure 35

Viewing release path


21/76

3.

Now lets look at how the Fabrikam Fiber team defined the process used to deploy their web

application. Navigate to Configure Apps | Release Templatesand then double-clickon the

Fabrikam Call Centertemplate.

Figure 36

Configuring release template

4.

The release template designer has a toolbox with control flow building blocks, servers, custom

components, and a bunch of other actions and tools to help with deployment. Select the

Propertieslink.

Figure 37

Viewing release template properties

5.

Here you can see that the release template is set and a build definition is assigned. Also, note

the option to allow builds to trigger releases. Triggering a release from a build requires the use

of a modified build template and the installation of the Release Management Client on the build

server.


22/76

Figure 38

Viewing release template properties

6.

Select the Closekey to close the Properties window.

7.

The first stage should be selected with its deployment sequence shown below. For the purposes

of this lab, the deployment sequence is relatively simple to help illustrate the concept. Select

the Collapse Allbutton so that we can dig into the example deployment sequence starting at a

high level of detail.

Figure 39

Location of Collapse All button

8.

The collapsed view shows just the VSALMserver, which means that all deployment tasks will

occur on just this server. If you look at the Toolbox, you will notice that there is a Serversnode.


23/76

This toolbox node shows all servers available to the environment configured for the currently

selected stage.

Figure 40

Deployment sequence showing server

9.

Expand the VSALMnode. In summary of the details to follow, the general deployment sequence

involves removing the existing web site from IIS, backing up the current bits, xcopy deploying

the new bits from the build, re-creating the web site in IIS, and finally rolling back if there are

failures.

Figure 41


24/76

Deployment sequence

10.

Expand the Remove Web Sitenode. This action was dragged and dropped onto the deployment

sequence from the IIStoolbox node. It is configured to remove the FabrikamDevsite from IIS.

Figure 42

Remove Web Site node

11.

Expand the Copy File or Foldernode. This action is from the Windows OStoolbox node and is

configured to back up the current web site location to a backup folder.

Figure 43

Copy File or Folder node

12.

Expand the Call Center Sitenode. Note the puzzle piece icon on the top-left, which indicatesthat it is an instance of a custom component.

Figure 44

Call Center Site node

13.

Lets look at this component by navigating to Configure Apps | Componentsand then double-

clickingon the Fabrikam Call Center component.


25/76

Figure 45

Viewing custom component configuration

14.

In the Sourcetab, note that the Builds with application option is selected. This means that

the component will inherit the team project and build definition from the release template. The

path to the package to deploy is currently set to [Build DropLocation]\_PublishedWebsites\FabrikamFiber.Web.

Figure 46


15.

Select the Deploymenttab.


26/76

Figure 47

Location of Deployment tab

16.

This component uses the XCopy Deployertool, which is backed by a script named irxcopy.cmd.

The Argumentsproperty is setup to copy all deployment source files to the Installation Pathparameter (which is exposed on the release template design surface).

Figure 48


17.

Return to the Fabrikam Call Centerrelease template and expand the Create Web Sitenode.

This creates the specified site in IIS.

Figure 49

Create Web Site node


27/76

18.

Finally, look at the Rollbacksequence, which restores the backup and re-creates the original

web site in IIS (if needed).

Figure 50

Rollback sequence

19.

All stages of this demonstration release template have an identical structure, albeit with

different parameters.


28/76

Figure 51

Viewing QA stage

Note: In the likely event that your stages have a similar structure, you can copy and paste

elements from one stage to another. You can even copy the entire deployment sequence from

one stage to another. In the event that some servers are not available on the target stage, you

will be prompted to replace those servers with available ones. Copying an entire deployment

sequence can be accomplished by right-clicking on a stage node in the Release Template and

then selecting the option to copy.

20.

Before we move on to see a release in action, lets take a peek at the available tools and

actions. Navigate to Inventory | Tools.


29/76

Figure 52Location of Tools tab

21.

The current set of configured tools provides the ability to execute command line statements,

manipulate files and processes, deploy databases and websites, install applications, manage

Azure virtual machines, and even run automated tests defined in Microsoft Test Manager. Some

of the tools are backed by scripts, while others are backed by executables. You can easily add in

your own tools if needed.

22.

Select the Actionstab.

Figure 53

Location of Actions tab

23.

Actions are specific applications of the tools. For example, a number of the defined actions

perform tasks in IIS using the IIS Deployer tool.


30/76

Figure 54

Viewing available actions

Note:Starting with Update 3, you can now tag your servers per environment and use those

tags as part of your deployment sequence. This allows you to specify deployment actions for

all servers in an environment that are tagged. For example, the following screenshot shows the

same deployment as was highlighted earlier in the exercise, but with all servers being tagged

with All tag and select servers with a Debug tag. In the event that more servers are added

to the environment, the release template itself does not need to be modified.

Exercise 4: Release Automation Example


31/76

In this exercise, you will configure a Team Foundation Server build for continuous integration, ensure

that it automatically triggers a release, and then execute/follow that release all the way through the

development, QA, and production stages.

1.

Log in as Brian Keller (VSALM\Brian). All user passwords are P2ssw0rd.

2.

Launch Visual Studio 2013from the taskbar and open Team Explorer. You should now beconnected to the FabrikamFiber team project. If you are not automatically connected to the

FabrikamFiber project, select the Connect to Team Projectsbutton ( ) to do so.

Figure 55

Team Explorer Home view

3.

Select the Buildstile.


32/76

Figure 56

Location of Builds tile

4.

Right-clickon the Nightly Fabrikam (Dev) build definition and select the Edit Build Definition

option.

Figure 57

Editing build definition

5.

Select the Triggertab.


33/76

Figure 58

Location of Trigger tab

6.

The name of the build implies that the Fabrikam Fiber application is built each night, even

though it is currently set to be manually triggered. Lets say that the team has decided to go

with the Continuous Integrationoption, to build on each check-in, so select that option.

Figure 59

Selecting Continuous Integration option

7.

Select the Processtab.


34/76

Figure 60

Location of Process tab

8.

As we pointed out in the previous exercise, a custom build process template needs to be used in

order for builds to be handed off to Release Management. Note that the

ReleaseDefaultTemplate.11.1.xamltemplate is selected.

Figure 61

Custom build process template

Note: The Release Management build process template can be found in the

%ProgramFiles(x86)%\Microsoft Visual Studio 12.0\Release Management\binfolder.

9.

As a quick aside, the custom build process template also contains the logic to tokenize your

configuration files. This logic assumes that in your solution, you have two versions of your

configuration files. One version is your normal configuration file used during local development,

and the other is a corresponding file that has the same content, except that instead of having

local values for your variables, tokens have been put there. The build activity will swap those

two files before doing the build, so that you end up with the tokenized version of the

configuration files in the drop location.

10.

Here is an example of how to achieve this: Lets say your solution contains a file called

web.config. You would need to copy that file (and keep them in sync), and name it


35/76

web.config.token. Your web.config file will stay the way it is now (and that will be used when

you run the app locally). The web.config.token file will contain tokens instead of values.

Figure 62

Example of token file

11.

Back to our build configuration, scroll down to the Release Managementsection of the build

process parameters and note that the Release Build parameter is set to True. Both the build

definition and Release Management need to be configured in order to allow a build to trigger a

release.

Figure 63

Location of Release Build option

Note: In the case of a nightly build, it may make sense to set the Release Target Stageto be

something other than production, perhaps a development or QA stage, but for demonstration

purposes, we will take the release all the way to production.

12.

Press Ctrl + Sto save the build definition. Everything should now be in place for a continuous

integration scenario where a source check in will trigger both a build and a release.

13.

In Team ExplorerHome, double-clickon the first FabrikamFiber.CallCenter.slnsolution.


36/76

Figure 64

Loading FabrikamFiber solution

14.

Launch Internet Explorerfrom the taskbar and select the FF DEVbutton from the favorites bar

to load the Fabrikam Fiber site currently deployed to the development environment. Youll have

to play along with the scenario here, as the QA and Production versions of the site are also on

the same machine, albeit on different ports.

Figure 65

Location of Fabrikam Fiber link (development)

15.

To pick a simple but visual change to the site for demonstration purposes, lets say that we need

to change Fabrikam Fiber Support to Fabrikam Fiber Support v2.0. Back in Visual Studio,

open_Layout.cshtmlfrom FabrikamFiber.Web | Views | Shared.


37/76

Figure 66Location of _Layout.cshtml

16.

In_Layout.cshtml, locate the h2 tag that contains the Support text and change it to be

Support v2.0.

Figure 67

Modifying the web site


38/76

17.

In Team ExplorerPending Changes, select the Check Inbutton. Select Yesif prompted to save

changes and check in.

Figure 68

Checking in change

18.

If you quickly open Team ExplorerBuilds, you should see that the check in triggered a build.

Double-clickon the build.

Figure 69

Opening build in progress

19.

Wait for the build to finish and then select the View Loglink.


39/76

Figure 70

Location of View Log link

20.

If you scroll down through the activity log, you should see the steps that have to do with

Release Management.

Figure 71

Activity log showing steps involving Release Management

21.

Launch the Release Managementdesktop client and navigate to Releases | Traffic Overview.


40/76

Figure 72

Loading Release Management traffic overview

22.

Note that the Fabrikam Call Centerrelease path now shows that another deployment is in

process in the development stage. Your numbers may be slightly different that the following

screenshot.

Figure 73

Traffic overview showing release in process

23.

Double-clickon the Dev stage for the Fabrikam Call Center release path.


41/76

Figure 74

Loading detailed traffic view for Dev stage

24.

Assuming that you have waited long enough for the deployment to complete, you should see

that the most recent release (top) is currently in the Dev stage waiting for approval.

Figure 75

Release history showing release in progress

25.

As a refresher, lets take a look at the Dev stageworkflow once again. No need to navigate

there in the application, just refer to the screenshot below.


42/76

Figure 76

Dev stage workflow configuration

26.

As you can see, the acceptance, deployment, and validation steps are all automated while we

are awaiting explicit approval before moving on to the QA stage. Specifically, the release is

waiting for Brian Keller to provide approval. Although not configured in this virtual machine,

Brian would receive an email alerting him about the pending approval.

27.

Select theMy Approval Requestslink to view pending approvals.

Figure 77

Location of My Approval Requests

28.

Double-clickon the pending approval.


43/76

Figure 78

Loading pending approval details

29.

Select the View Sequencelink.

Figure 79

Location of View Sequence link

30.

We can look at the deployment sequence and see all of the specific parameters that were (or

will be) used for each stage. Note that these ultimately become historical (and read-only) for

each specific release.

Figure 80


44/76

Deployment sequence showing parameters

31.

Select the View Loglink.

Figure 81

Location of View Log link

32.

The log shows the details and status for each step of the release process. This shows that the

deployment was automatically accepted, deployed, and validated for the Dev stage and is

now waiting for approval. The Deploystep also has additional detailsselect the ellipses

button in the details column.

Figure 82

Location of ellipses button

Note: You can view future steps as well by selecting the Include Future Steps option at the

bottom of the log.

33.

The deployment log shows details for each action performed. Select the View Loglink for the

Remove Web Siteaction. Use Notepadif prompted.

Figure 83

Viewing action log


45/76

Note: If a specific action fails, the output from the underlying tool used should provide

debugging information to help determine if there is a problem with the target environment or

the deployment sequence.

34.

This log shows that the FabrikamDev web site was deleted successfully.

Figure 84

Viewing successful action log

35.

Closethe Notepadwindow and the Deployment Logwindow.

36.

Before we approve the release, lets look at the deployed site in Internet Explorer. Select the

FF DEV link from the favorites bar.

Figure 85

Location of FF DEV link

37.

Here we can see that Support v2.0 shows up as expected.


46/76

Figure 86

Deployment to the development environment is a success

38.

In Release Management, return to My Approval Requests, select the release, and then select

the Approvebutton.

Figure 87

Approving the release to the development stage

39.

In the Approval Confirmationwindow, enter a comment such as Dev deployment looks good

and then select the OKbutton.

Figure 88

Adding an approval confirmation comment

40.

The deployment will then transition to the QA stage and automatically deploy the web site to

the configured environment. Refreshthe My Approval Requests view until the release stops for

QA approval.


47/76

Figure 89

Waiting for QA approval

41.

Once the deployment is complete and automatically validated, someone from the QA Team will

need to approve the release. Brian is a member of the team, so go ahead and load the QA site

using the FF QA favoritelink in Internet Explorer.

Figure 90

Deployment to the QA environment is a success

42.

Back in Release Management, navigate to the My Approval Requestsview, select the

deployment, and then select the Approvebutton.

Figure 91

Approving the release to the QA stage

43.

In the Approval Confirmationwindow, enter a comment such as QA deployment looks good

and then select the OKbutton.


48/76

Figure 92

Adding an approval confirmation comment

44.

As a refresher, lets take a look at the Prod stage workflow once again. No need to navigate

there in the application, just refer to the screenshot below. Note that the acceptance step is not

automated as it was for the previous stages. This means that the assigned approver must

explicitly sign off on before the actual deployment to production will begin.

Figure 93

Prod stage workflow configuration

45.

Select the pending approval request in My Approval Requestsand note that Brian has a few

options to consider besides approval - including reassignment and rejection. Lets go ahead and


49/76

approve the deployment to production since the QA Team signed off on the previous stage.

Select the Approvebutton.

Figure 94

Approve the request to deploy to production

46.

In the Approval Confirmationwindow, enter a comment such as Ready for production. Note

that you can deploy immediately or schedule the deployment for later. Use the default option

to deploy nowand then select the OKbutton.

Figure 95

Approve the request now

47.

Go ahead and load the production site using the FF PROD favorite in Internet Explorer. You

may need to refresh the page a few times before the build isdeployed (displaying Support

v2.0).

Figure 96

Deployment to the production environment is a success


50/76

48.

The Ops Team now needs to validate the deployment. Select the request and then select the

Approvebutton.

Figure 97

Approving the deployment to production

49.

In the SuccessfulDeployment Confirmationwindow, enter a comment such as Ops approved

and then select the OKbutton. The operations team may have their own suite of tests that they

run to ensure that everything is running as expected and ready for end-users.

Figure 98

Approve the deployment to production

50.

Navigate to Releases | Releasesand note that the release has made it to the target stage of

Prod and has a Status of Released.

Figure 99

Build has been released to production

51.

There are circumstances where being able to manually trigger the release of a specific build

using the same process would be useful. For example, lets say that it has been discovered that

the production site has some scaling issues (that unfortunately werent discovered before the

previous release made it to production), and we would like the QA team to do some

comparative testing using their toolset against the QA environment.


51/76

52.

Select the Configure Apps | Release Templatestab, select the Fabrikam Call Centertemplate,

and then click the New Releasebutton.

Figure 100

Location of New button

53.

Name the release QA Testing, select the Fabrikam Call Centerrelease template, select a

target stage of QA(we dont want to go all the way to production), and then select the

Select link next to the Build field.

Figure 101

Manually triggering a release

54.

In the Search Buildswindow, select the oldest build.

Figure 102

Selecting a build

55.

To start the release, select the Startbutton (optional).


52/76

Figure 103

Location of Start button

56.

If you were to follow this release to the target stage using the same process as before, you

would end up with the desired build deployed to the QA environment.

57.

To learn more about Release Management, please visit

http://www.visualstudio.com/explore/release-management-vs.

Exercise 5: Release Management Support

for Azure and DSC (optional)

Note: This optional exercise requires a Windows Azure subscription. If you have a MSDN subscription,

you can take advantage of the providedAzure benefits.

In this exercise, you will walk through the process of connecting Release Management to a Windows

Azure subscription, defining a release template that deploys Fabrikam Fiber to an Azure virtual machine

using DSC, and finally triggering a release to Azure. The features shown here are new as of Update 3.

1.

Before moving on with this exercise, you will first need to start the Hyper-V Time

Synchronization Serviceto ensure that the virtual machine date and time match the real world.
http://www.visualstudio.com/explore/release-management-vshttp://www.visualstudio.com/explore/release-management-vshttp://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-b/http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-b/http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-b/http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-b/http://www.visualstudio.com/explore/release-management-vs


53/76

The easiest way to do this is to execute the EnableVMTimeSync.batfile from c:\util. Right-click

on the script and select the option to Run as Administrator.

Figure 104

Ensuring that virtual machine date and time match host machine

2.

In order to configure Release Management to work with your Azure subscription, you will first

need to download the publish profile. This is easy to do using Windows Azure PowerShell (pre-

installed on the virtual machine for your convenience). Search for and launch Microsoft Azure

PowerShellfrom the Start screen.

Figure 105

Launching Microsoft Azure PowerShell

3.

Type Get-AzurePublishSettingsFile into the Microsoft Azure PowerShell window and then

press Enter.


54/76

4.

Enter your credentials, select the subscription file that you wish to download (if you have more

than one subscription), and finally select the Submitbutton to download the publish settings

file.

Figure 106

Downloading publish settings for selected subscription

Note: Please be aware that the publish settings file contains sensitive information such as an

encoded management certificate.

5.

Savethe publish settings file to a location of your choosing.

6.

Open the publish settings file using Notepad. We will copy and paste the needed values from

here in a few steps.

7.

Since you already have a browser logged in with your Microsoft account, type

manage.windowsazure.cominto the address bar to load the management portal. You are going

to create a virtual machine and a storage account to use with Release Management later on.

8.

Create a new virtual machine from the gallery (click the Newbutton, Compute, Virtual

Machine, From Galleryoption) with the following options:

Image: Windows Server 2012 R2 Datacenter

Version Release Date: use the latest available (default)

Virtual Machine Name: Web-VM1

Tier: Standard


55/76

Size: A1

New User Name: DemoAdmin

Password:

Cloud Service: Create a new cloud service

Cloud Service DNS Name:

Region:

Storage Account:

Availability Set: (None)

Endpoints: use defaults and add in HTTP (this allows port 80 traffic to be sent to VM)

For other options, use the defaults and then start the VM creation process. This will

take a few minutes.

9.

Create a new storage account in the same region that you used to house your virtual machine

(click the Newbutton, Storage, Quick Create) with the following options:

URL:

Location/Affinity Group:

Replication:

10.

Create a new SQL database in the same region used to house your virtual machine (click the

Newbutton, SQL Database, Custom Create) with the following options:

Name:

Edition: Web

Max Size: 1 GB

Collation:

Server:

Note:In the event that you need to create a new server, provide your desired login name and

credentials, but select the same region as you have been using in previous steps.


56/76

11.

Wait for the virtual machine and storage account to be created and in the Running/Online state

before moving on.

12.

Launch the Release Management clientfrom the taskbar.

13.

Select the Administration | Manage Azuretab and then select the Newbutton.

Figure 107

Creating connection to Azure subscription

14.

For the Name, enter something such as Demo Subscription.

15.

For the Subscription ID, copy and paste the value from your publish settings file (do not include

the quotes).

16.

For the Management Certificate Key, copy and paste the value from your publish settings file

(do not include the quotes).

17.

For the Storage Account Key, enter the name of the storage account that you would like

Release Management to use when uploading bits for deployment.

18.

Select the Save & Closebutton.

Figure 108

Creating connection to Azure subscription

19.

Now we can link to the Azure subscription in order to pull in the virtual machine that we

created earlier. Select the Configure Paths | Environmentstab and then select the New vNext:

Azureoption from the drop-down.


57/76

Figure 109

Creating a new Azure environment

20.

Select the Link Azure Environmentbutton.

Figure 110

Linking Azure Environment

21.

In the Azure Environmentswindow, select the subscription that you created earlier.

Figure 111

Selecting subscription containing desired environment

22.

Select the Azure environment that you created earlier (this is the DNS name of the cloud

service) and then select the Linkbutton.

Figure 112

Selecting desired environment


58/76

23.

Set the Ownerto be Brian Keller.

24.

Select the Link Azure Serversbutton.

Figure 113

Linking Azure Servers

25.

In the Azure Serverswindow, select the Azure virtual machine that you created earlier and then

select the Linkbutton. Note that applying some sort of naming scheme here makes it more

evident that the Azure service and virtual machine are meant for production deployments of a

web site.

Figure 114

Linking to specific servers in Azure

26.

Select the Save & Closebutton for the new environment.


59/76

Figure 115

Saving the new environment for use with Release Management

27.

Now we can really dig into the deployment experience when working with Azure in ReleaseManagement. In this case, we are going to see how one might deploy a web application to an

Azure virtual machine that does not have a deployment agent running on it, using a push model

of deployment and Desired State Configuration script. Select the Configure Paths | vNext

Release Pathstab and then select the Newbutton.

Figure 116

Creating a new release path to Azure

28.

For the Name, enter something like Fabrikam Fiber Cloud.

Figure 117

Creating a name for release path

29.

In the Stagestab, select the Addbutton.


60/76

Figure 118

Defining a stage for release path

30.

For demonstration purposes and simplicity, letsjust define a single production stage using the

new environment running in Azure. For the Stagedrop-down, select the Prod option. For

Environment, select the environment that you just linked.

Figure 119

Defining a new stage

31.

For demonstration purposes and simplicity, automateall steps and select the Ops Teamfor

each step.

Figure 120

Defining a new stage


61/76

32.

Select Save & Closeto save and close the new release path definition.

33.

Now you need to define a component that will be used to package up the Fabrikam Fiber

website build for deployment to Azure. Select Configure Apps | Componentsand then select

the New vNextbutton.

Figure 121

Creating a new component

34.

For the Name, use something like Fabrikam Call Center - Cloud.

35.

In the Sourcetab, use the default option that states Builds with application and specify the

path to package to be *Build Drop Location+\_PublishedWebsites\FabrikamFiber.Web.Select

the Save & Closebutton.

Figure 122

Defining a component for the sample website

36.

Before we create the release template, lets take a quick peek at some Desired State

Configuration (DSC) script that was created ahead of time that will do most of the setup and

configuration work once pushed out to the Azure. Launch Visual Studio 2013from the task bar.

37.

Double-click on the first FabrikamFiber.CallCenter.slnsolution from Team Explorer - Home.

38.

In Solution Explorer, expand the FabrikamFiber.Webnode and open FFDeploy.ps1from the

Deploy folder.


62/76

Figure 123

Opening DSC script in Visual Studio

39.

This DSC script defines the necessary configuration for the Fabrikam Fiber website in a

declarative manner. If you scroll down and glance at the configuration sections, you should be

able to determine what is happening here at a high level. The IIS role is installed (if needed), the

ASP.NET 4.5 role is installed (if needed), the website bits are copied to the server, the default

website is stopped, and the Fabrikam Fiber site is created and started. At the very end, the

configuration is enacted using the specified configuration data.


63/76

Figure 124

DSC script

Note: DSC is a PowerShell extension that ships with Windows Server 2012 R2 and Windows

8.1, although you can bring support for DSC down to Windows Server 2008 R2 and Windows 7

by installing the Windows Management Framework 4.0.

40.

Most of the configuration modules used here are built into DSC. However, you can use or create

custom modules to tackle other needed tasks. Note that a module named xWebAdministration

is imported at the beginning of the configuration.


64/76

Figure 125

DSC script

Note: The xWebAdministration module contains a number of resources that can be used for

configuring IIS, including xWebsite that is used in this script. You can acquire a number of

different modules for use in DSC scripts from the PowerShell Resource Gallery (currently in

preview form athttps://msconfiggallery.cloudapp.net).

41.

Note that the xWebAdministration module is included in source control within the Deploy

folder. This folder is deployed with the website, and therefore made available to script that runs

on the target servers during deployment.

Figure 126

xWebAdministration folder deployed with website

42.

Now lets take a quick peek at the configuration script by opening FFDeployConfig.ps1. Note

that although we are looking at this script first, it is actually the first one to run on the server.

Figure 127

Insert Caption

43.

The first part of this script places the xWebAdministration module in a discoverable location on

the server. Next, a firewall rule is created to allow traffic in via port 80 if needed. The most

important part to point out is the definition of $ConfigData(which is referenced when theconfiguration is enacted).
https://msconfiggallery.cloudapp.net/https://msconfiggallery.cloudapp.net/https://msconfiggallery.cloudapp.net/https://msconfiggallery.cloudapp.net/


65/76

Figure 128DSC configuration script

44.

Open the web.configfile from the root of the FabrikamFiber.Webproject so that we can

update the connection string.

Figure 129

Opening web.config

45.

In the Azure management portal, navigate to the dashboard for the database that you created

earlier and then click on the View SQL Database connection strings link.


66/76

Figure 130

Viewing the connection string for the database

46.

Select the connection string shown for ADO.NETand then press Ctrl+C to copy it.

Figure 131


67/76

Copying connection string for database

47.

Switch back to Visual Studio and then paste (Ctrl+V) the connection string at the appropriate

place for the connection string named FabrikamFiber-Express.

Figure 132

Location to place new connection string

48.

Locate the part of the connection string with the {your_password_here}placeholder and

replace it with the real value.

49.Check inyour changes.

50.

Since we already have a Fabrikam Fiber build defined, lets go ahead and make use of that for

our demonstration purposes. However, to avoid confusion later we should modify it so that a

new release is not triggered during the build. In Team Explorer - Builds, right-click on the

Nightly Fabrikam (Dev)build definition and select Edit Build Definition.

Figure 133

Editing build definition

51.

In the Processtab, change the Release Buildoption to False(see the Release section at the

bottom). We will manually create a new release later.


68/76

Figure 134

Modifying build definition

52.

Press Ctrl+Sto save changes to the build definition.

53.

Right-click on the build definition and select Queue New Build.

54.

Use the default options for the build by pressing the Queuebutton.

55.

Wait for the build to finish and take note of the build number.

56.

Return to the Release Managementclient and navigate to the Configure Apps | vNext Release

Templatestab and select the Newbutton.

Figure 135

Creating a new release template

57.

For Name, use something like Fabrikam Call Center - Cloud.


69/76

58.

For Release Path, select the release path that you created earlier.

59.

Select the build definitionfor the FabrikamFiberproject.

60.

Select the Createbutton to create the release template.

Figure 136

Creating a new release template

61.

In the Toolbox, right-click on the Componentsnode and select Add.


70/76

Figure 137

Linking component to release template

62.

Select the component that you created earlier and then select the Link button.

Figure 138

Linking component to release template

63.

Drag and drop an instance of the Deploy To Azure Environmentaction to the Deployment

Sequence.


71/76

Figure 139

Adding deployment action to deployment sequence

64.

Expand the Deploy To Azure Environmentaction within the Deployment Sequence.

Figure 140

Adding deployment action

65.

Now it is time to fill in the configuration variables for the Deploy To Azure Environmentaction.

66.

Type the configuration variables as shown in the screenshot below, just make sure that your

ServerName, UserName, Password, and ComponentNamematch the correct values for your

setup (you can find ServerName and ComponentName specified in the Toolbox).


72/76

Figure 141

Providing configuration variables

67.

Select the Savebutton.

Figure 142

Saving the new release template


73/76

68.

At this point, you should be ready to create a new release to Azure. Select the New Release

button.

Figure 143

Creating a new release

69.

In the Propertieswindow, select the most recent build by clicking on the Selectlink.

Figure 144

Selecting the build to release

70.

Double-clickon the most recent build to select it.

Figure 145

Selecting the build to release

71.

Select the Startbutton to initiate the build.


74/76

Figure 146

Starting the release of Fabrikam Fiber to Azure

72.

You can monitor the progress of the release in the Release Management client. Note that it will

take a few minutes for the first release to be deployed to your Azure virtual machine, as the DSC

script will install IIS, ASP.NET 4.5, and so on if they havent been already (which will be the case

on a default installation of Windows Sever).


75/76


76/76

Figure 149

Fabrikam Fiber running in Azure

To give feedback please write [email protected]

Copyright 2014 by Microsoft Corporation. All rights reserved.
mailto:[email protected]:[email protected]:[email protected]:[email protected]

Embracing Continuous Delivery With Release Management for Visual Studio 2013

Documents