Hands-On LabEmbracing Continuous Delivery with Release Management for Visual Studio 2015Lab version: 14.0.23107.0

Last updated: 9/11/2015

TABLE OF CONTENT

EMBRACING CONTINUOUS DELIVERY WITH RELEASE MANAGEMENT FOR VISUAL STUDIO 2015........................................................................................................................................1

OVERVIEW.....................................................................................................................................3Prerequisites...........................................................................................................................3About the Fabrikam Fiber Scenario........................................................................................3Exercises.................................................................................................................................3

EXERCISE 1: RELEASE MANAGEMENT OVERVIEW..................................................................................4Task 1: Release Management System Overview.................................................................4Task 2: Release Management Web Client...........................................................................5

EXERCISE 2: CONFIGURING RELEASE MANAGEMENT............................................................................11Task 1: Release Management and TFS Configuration.......................................................11Task 2: Group and User Configuration..............................................................................14Task 3: Configuring Deployment Agents and Environments.............................................18

EXERCISE 3: DEFINING A RELEASE PATH AND TEMPLATE......................................................................20Task 1: Release Path and Template Configuration............................................................20Task 2: Using Components................................................................................................25Task 3: Configuring Deployment Stages............................................................................27Task 4: Available Deployment Tools and Actions..............................................................29

EXERCISE 4: RELEASE AUTOMATION EXAMPLE....................................................................................32Task 1: Enabling Continuous Integration with Release Management...............................32Task 2: Initiating a Release using Continuous Integration.................................................36Task 3: Monitoring the Build and Release.........................................................................39Task 4: Release Workflow and Approval Process..............................................................43Task 5: Initiating a Manual Release...................................................................................51

EXERCISE 5: RELEASE MANAGEMENT SUPPORT FOR AZURE AND DSC (OPTIONAL)....................................53Task 1: Setting up Azure Resources...................................................................................53Task 2: Configuring Azure Resources in Release Management.........................................56Task 3: Creating Release Path...........................................................................................59Task 4: Creating Component.............................................................................................61Task 5: Defining Deployment using Desired State Configuration......................................62Task 6: Additional Application-Specific Configuration.......................................................65Task 7: Defining and Configuring the Release Template...................................................74Task 8: Initiating a Release to Azure.................................................................................78

Overview

In this lab, you will learn about Release Management for Visual Studio 2015 and its suite of release and deployment tools that automate the deployment of applications across the desktop, server, and the cloud. Release Management for Visual Studio 2015 helps development and operations teams integrate with Team Foundation Server 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 2015 virtual machine provided by Microsoft. For more information on acquiring and using this virtual machine, please see this 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.

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 Example

5. (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.

Task 1: Release Management System Overview

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

2. The goal of Release Management’s 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.

Figure 1Release Management components

Note: There is also the option of deploying to environments that support DSC (Desired State Configuration). 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.

Note: This self-contained virtual machine has all Release Management components installed on it for demonstration purposes, including the deployment service.

Task 2: Release Management Web Client

1. 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 to http://vsalm:1000/ ReleaseManagement . Note that we do not currently have any pending approval requests.

Figure 2Release Management web application

2. Select the Previously Approved link and note that there were releases triggered by a build of the Fabrikam Call Center.

Figure 3Viewing previous approvals

3. Select the link displaying the number of deployed components (just underneath the name Brian Keller).

Figure 4Location of components link

4. 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 5Viewing components deployed

5. Press the Escape key to close the dialog window.

6. Note that we can see at a glance that the deployment is currently in the production stage. Select the stages link to view the historical workflow and approvals that occurred to get to that point.

Figure 6Location of stages link

7. 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

8. Select the Previous Stage link.

Figure 8Location of Previous Stage link

9. 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“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.

10. Select the Previous Stage link 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

11. Press the Escape key to close the dialog window.

12. 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.

13. 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.

14. 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.

15. 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.

Task 1: Release Management and TFS Configuration

1. Launch the Release Management client from the taskbar.

Figure 11Release Management client splash screen

2. By default, Release Management will load the Traffic Overview tab 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 12Traffic overview

3. Let’s take a quick look at some of the main configuration tasks that need to be addressed when installing and configuring Release Management. Select the Administration tab followed by the Manage TFS link.

Figure 13TFS connection configuration

4. Double-click on the TFS connection that has already been setup.

Figure 14Loading configuration for TFS connection

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 15Configuring account to connect to TFS

6. Other important settings can be configured in Administration | Settings. The System System Settings tab (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 16System settings

7. Select the Deployer Settings tab 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.

Figure 17Deployer settings

Task 2: Group and User Configuration

1. Let’s take a quick look at the setup of users and groups for Release Management. Navigate to Administration | Manage Users.

Figure 18User configuration

2. Double-click on the Brian Keller user.

Figure 19Viewing user configuration details

3. The Brian Keller user is associated with the windows account VSALM\Brian, is designated a Release Manager, and is an active member of a few different teams.

Figure 20Viewing user configuration details

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

Figure 21Group configuration

5. 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 22Importing groups from AD and TFS

Note: Synchronization is manual (using the Refresh button) unless the setting AD/TFS-Based Group Refresh Interval is setup to something other than 0 minutes (which is the default).

6. Double-click on the QA Team.

Figure 23Viewing group details

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

Figure 24Viewing group members

8. Select the Security tab.

Figure 25Location of Security tab

9. The Security tab 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.

Figure 26Group security settings

10. Navigate to Administration | Manage Pick Lists and take note of the Stage Types defined here. The stage type names defined here are completely arbitrary, and therefore can be molded to fit your desired release strategy.

Figure 27Configuring stage types

Task 3: Configuring Deployment Agents and Environments

1. Servers to be used for deployment must have the Microsoft Deployment Agent service 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 | Servers and note that the deployment agent service has already been setup and configured for this virtual machine.

Figure 28Configuring servers

Note: Although we won’t do so here, the recommended way to add additional deployment servers is to select the drop-down arrow next to the New button and then select Scan for Agents.

2. Double-click on the VSALM server.

Figure 29Configuring servers

3. 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 30Configuring servers

4. Navigate to Configure Paths | Environments.

5. 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-click on the first environment named “Int-Dev”.

Figure 31Viewing environment configuration

6. 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 Security tab.

Figure 32Viewing environment configuration

Exercise 3: Defining a Release Path and Template

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.

Task 1: Release Path and Template Configuration

1. Now let’s look at a release path definition. Navigate to Configure Paths | Agent-based Release Paths and double-click on the Fabrikam Call Center release path.

Figure 33Viewing 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 34Viewing release path

3. Now let’s look at how the Fabrikam Fiber team defined the process used to deploy their web application. Navigate to Configure Apps | Agent-based Release Templates and then double-click on the Fabrikam Call Center template.

Figure 35Configuring 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 Properties link.

Figure 36Viewing 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.

Figure 37Viewing release template properties

6. Select the Close key 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 All button so that we can dig into the example deployment sequence starting at a high level of detail.

Figure 38Location of Collapse All button

8. The collapsed view shows just the VSALM server, 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 Servers node.

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

Figure 39Deployment sequence showing server

9. Expand the VSALM node. 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 40

Deployment sequence

10. Expand the Remove Web Site node. This action was dragged and dropped onto the deployment sequence from the IIS toolbox node. It is configured to remove the “FabrikamDev” site from IIS.

Figure 41Remove Web Site node

11. Expand the Copy File or Folder node. This action is from the Windows OS toolbox node and is configured to back up the current web site location to a backup folder.

Figure 42Copy File or Folder node

Task 2: Using Components

1. Expand the Fabrikam Call Center node. Note the puzzle piece icon on the top-left, which indicates that it is an instance of a custom component.

Figure 43Call Center Site node

2. Let’s look at this component by navigating to Configure Apps | Components and then double-clicking on the Fabrikam Call Center component.

Figure 44Viewing custom component configuration

3. In the Source tab, 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 Drop Location]\_PublishedWebsites\FabrikamFiber.Web.

Figure 45Viewing custom component configuration

4. Select the Deployment tab.

5. This component uses the XCopy Deployer tool, which is backed by a script named irxcopy.cmd. The Arguments property is setup to copy all deployment source files to the Installation Path parameter (which is exposed on the release template design surface).

Figure 46Viewing custom component configuration

Task 3: Configuring Deployment Stages

1. Return to the Fabrikam Call Center release template and expand the Create Web Site node. This creates the specified site in IIS.

Figure 47Create Web Site node

2. Finally, look at the Rollback sequence, which restores the backup and re-creates the original web site in IIS (if needed).

Figure 48Rollback sequence

3. All stages of this demonstration release template have an identical structure, albeit with different parameters.

Figure 49Viewing 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.

Task 4: Available Deployment Tools and Actions

1. Before we move on to see a release in action, let’s take a peek at the available tools and actions. Navigate to Inventory | Tools.

Figure 50Location of Tools tab

2. 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.

3. Select the Actions tab.

Figure 51Location of Actions tab

4. Actions are specific applications of the tools. For example, a number of the defined actions perform tasks in IIS using the IIS Deployer tool.

Figure 52Viewing available actions

Note: You can also 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

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.

Task 1: Enabling Continuous Integration with Release Management

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

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

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

Figure 53Team Explorer – Home view

3. Select the Builds tile.

Figure 54Location of Builds tile

4. Right-click on the “Nightly Fabrikam (Dev)” build definition and select the Edit Build Definition option.

Figure 55Editing build definition

5. Select the Trigger tab.

Figure 56Location 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. Let’s say that the team has decided to go with the Continuous Integration option, to build on each check-in, so select that option.

Figure 57Selecting Continuous Integration option

7. Select the Process tab.

Figure 58Location 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 ReleaseTfvcTemplate.12.xaml template is selected.

Figure 59Custom build process template

Note: The Release Management build process templates can be found in the %ProgramFiles(x86)%\Microsoft Visual Studio 14.0\Release Management\bin folder.

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: Let’s say your solution contains a file called web.config. You would need to copy that file (and keep them in sync), and name it 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 60Example of token file

11. Back to our build configuration, scroll down to the Release Management section 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 61Location of Release Build option

Note: In the case of a nightly build, it may make sense to set the Release Target Stage to 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 + S to 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.

Task 2: Initiating a Release using Continuous Integration

1. In Team Explorer – Home, double-click on the first FabrikamFiber.CallCenter.sln solution (the Dev branch).

Figure 62Loading FabrikamFiber solution

2. Launch Internet Explorer from the taskbar and select the FF DEV button from the favorites bar to load the Fabrikam Fiber site currently deployed to the development environment. You’ll 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 63Location of Fabrikam Fiber link (development)

3. To pick a simple but visual change to the site for demonstration purposes, let’s say that we need to change “Fabrikam Fiber Support” to “Fabrikam Fiber Support v2.0”. Back in Visual Studio, open _Layout.cshtml from FabrikamFiber.Web | Views | Shared.

Figure 64Location of _Layout.cshtml

4. In _Layout.cshtml, locate the h2 tag that contains the “Support” text and change it to be “Support v2.0”.

Figure 65

Modifying the web site

5. In Team Explorer – Pending Changes, select the Check In button. Select Yes if prompted to save changes and check in.

Figure 66Checking in change

Task 3: Monitoring the Build and Release

1. If you quickly open Team Explorer – Builds, you should see that the check in triggered a build. Double-click on the build.

Figure 67Opening build in progress

2. Wait for the build to finish and then take a quick look at the log. If you scroll down through the activity log, you should see the steps that have to do with Release Management.

Figure 68Activity log showing steps involving Release Management

3. Launch the Release Management desktop client and navigate to Releases | Traffic Overview.

Figure 69Loading Release Management traffic overview

4. Note that the Fabrikam Call Center release path now shows that another deployment is in process in the development stage. Your numbers may be slightly different that the following screenshot.

Figure 70Traffic overview showing release in process

5. Double-click on the “Dev” stage for the Fabrikam Call Center release path.

Figure 71Loading detailed traffic view for “Dev” stage

6. 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 72Release history showing release in progress

7. As a refresher, let’s take a look at the “Dev” stage workflow once again. No need to navigate there in the application, just refer to the screenshot below.

Figure 73“Dev” stage workflow configuration

8. 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.

Task 4: Release Workflow and Approval Process

1. Select the My Approval Requests link to view pending approvals.

Figure 74Location of My Approval Requests

2. Double-click on the pending approval.

Figure 75Loading pending approval details

3. Select the View Sequence link.

Figure 76Location of View Sequence link

4. 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 77Deployment sequence showing parameters

5. Select the View Log link.

Figure 78Location of View Log link

6. 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 Deploy step also has additional details – select the ellipses button in the details column.

Figure 79Location of ellipses button

Note: You can view future steps as well by selecting the “Include Future Steps” option at the bottom of the log.

7. The deployment log shows details for each action performed. Select the View Log link for the Remove Web Site action. Use Notepad if prompted.

Figure 80Viewing action log

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.

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

Figure 81Viewing successful action log

9. Close the Notepad window and the Deployment Log window.

10. Before we approve the release, let’s look at the deployed site in Internet Explorer. Select the “FF DEV” link from the favorites bar.

Figure 82Location of “FF DEV” link

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

Figure 83Deployment to the development environment is a success

12. In Release Management, return to My Approval Requests, select the release, and then select the Approve button.

Figure 84Approving the release to the development stage

13. In the Approval Confirmation window, enter a comment such as “Dev deployment looks good” and then select the OK button.

Figure 85Adding an approval confirmation comment

14. The deployment will then transition to the “QA” stage and automatically deploy the web site to the configured environment. Refresh the My Approval Requests view until the release stops for QA approval.

Figure 86Waiting for QA approval

15. 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” favorite link in Internet Explorer.

Figure 87Deployment to the QA environment is a success

16. Back in Release Management, navigate to the My Approval Requests view, select the deployment, and then select the Approve button.

Figure 88Approving the release to the QA stage

17. In the Approval Confirmation window, enter a comment such as “QA deployment looks good” and then select the OK button.

Figure 89Adding an approval confirmation comment

18. As a refresher, let’s 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 90“Prod” stage workflow configuration

19. Select the pending approval request in My Approval Requests and note that Brian has a few options to consider besides approval - including reassignment and rejection. Let’s go ahead and approve the deployment to production since the QA Team signed off on the previous stage. Select the Approve button.

Figure 91Approve the request to deploy to production

20. In the Approval Confirmation window, 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 now and then select the OK button.

Figure 92Approve the request now

21. 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 is fully deployed (displaying “Support v2.0”).

Figure 93Deployment to the production environment is a success

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

Figure 94Approving the deployment to production

23. In the Successful Deployment Confirmation window, enter a comment such as “Ops approved” and then select the OK button. 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 95Approve the deployment to production

24. Navigate to Releases | Releases and note that the release has made it to the target stage of “Prod” and has a Status of “Released”.

Figure 96Build has been released to production

Task 5: Initiating a Manual Release

1. There are circumstances where being able to manually trigger the release of a specific build using the same process would be useful. For example, let’s say that it has been discovered that the production site has some scaling issues (that unfortunately weren’t 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.

2. Select the Configure Apps | Agent-based Release Templates tab, select the Fabrikam Call Center template, and then click the New Release button.

Figure 97Location of New button

3. Name the release “QA Testing”, select the Fabrikam Call Center release template, select a target stage of QA (we don’t want to go all the way to production), and then select the “Select…” link next to the Build field.

Figure 98Manually triggering a release

4. In the Search Builds window, select the oldest build.

Figure 99Selecting a build

5. (Optional) To start the release, select the Start button.

Figure 100Location of Start button

6. (Optional) 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.

7. 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 provided Azure 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.

Task 1: Setting up Azure Resources

1. One bit of housekeeping before we move on. If you are continuing from the previous exercise, change the Trigger for the “Nightly Fabrikam (Dev)” build definition back to Manual (we previously changed it to Continuous Integration).

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 PowerShell from the Start screen.

Figure 101Launching Microsoft Azure PowerShell

3. Type “Get-AzurePublishSettingsFile” into the Microsoft Azure PowerShell window and then press Enter.

4. Enter your credentials, select the subscription file that you wish to download (if you have more than one subscription), and finally select the Submit button to download the publish settings file.

Figure 102Downloading publish settings for selected subscription

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

5. Save the 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.com into 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 New button, Compute, Virtual Machine, From Gallery option) 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

◦ Size: A1

◦ New User Name: DemoAdmin

◦ Password: <your choice>

◦ Cloud Service: Create a new cloud service

◦ Cloud Service DNS Name: <your choice, something like “CallCenter-Prod” that reflects an environment that could conceivably contain many virtual machines with different roles>

◦ Region: <your choice, just ensure that storage account you use is the same>

◦ Storage Account: <your choice>

◦ 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 New button, Data Services, Storage, Quick Create) with the following options:

◦ URL: <your choice>

◦ Location/Affinity Group: <use same as used for virtual machine creation>

◦ Replication: <your choice>

10. Create a new SQL database in the same region used to house your virtual machine (click the New button, Data Services, SQL Database, Custom Create) with the following options:

◦ Name: <your choice>

◦ Service Tier: Basic

◦ Server: <select existing, or create new if necessary>

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.

11. Please wait for the virtual machine, storage account, and SQL database are in the Running/Online state before moving on. This will take a few minutes.

Task 2: Configuring Azure Resources in Release Management

1. Launch the Release Management client from the taskbar.

2. Select the Administration | Manage Azure tab and then select the New button.

Figure 103Creating connection to Azure subscription

3. For the Name, enter something such as “Demo Subscription”.

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

5. For the Management Certificate Key, copy and paste the value from your publish settings file (do not include the quotes).

6. 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.

7. Select the Save & Close button.

Figure 104Creating connection to Azure subscription

8. Now we can link to the Azure subscription in order to pull in the virtual machine that we created earlier. Select the Configure Paths | Environments tab and then select the New vNext: Azure option from the drop-down.

Figure 105Creating a new Azure environment

9. Select the Link Azure Environment button.

Figure 106Linking Azure Environment

10. In the Azure Environments window, select the subscription that you created earlier.

Figure 107Selecting subscription containing desired environment

11. Select the Azure environment that you created earlier (this is the DNS name of the cloud service) and then select the Link button.

Figure 108Selecting desired environment

12. Set the Owner to be Brian Keller.

13. Select the Link Azure Servers button.

Figure 109

Linking Azure Servers

14. In the Azure Servers window, select the Azure virtual machine that you created earlier and then select the Link button. 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 110Linking to specific servers in Azure

15. Select the Save & Close button for the new environment.

Figure 111Saving the new environment for use with Release Management

Task 3: Creating Release Path

1. Now we can really dig into the deployment experience when working with Azure in Release Management. 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 Paths tab and then select the New button.

Figure 112Creating a new release path to Azure

2. For the Name, enter something like “Fabrikam Fiber Cloud”.

Figure 113Creating a name for release path

3. In the Stages tab, select the Add button.

Figure 114Defining a stage for release path

4. For demonstration purposes and simplicity, let’s just define a single production stage using the new environment running in Azure. For the Stage drop-down, select the “Prod” option. For Environment, select the environment that you just linked.

Figure 115Defining a new stage

5. For demonstration purposes and simplicity, automate all steps and select the Ops Team for each step.

Figure 116Defining a new stage

6. Select Save & Close to save and close the new release path definition.

Task 4: Creating Component

1. 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 | Components and then select the New vNext button.

Figure 117Creating a new component

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

3. In the Source tab, 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 & Close button.

Figure 118Defining a component for the sample website

Task 5: Defining Deployment using Desired State Configuration

1. Before we create the release template, let’s 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 2015 from the task bar.

2. Double-click on the first FabrikamFiber.CallCenter.sln solution from Team Explorer - Home.

3. In Solution Explorer, expand the FabrikamFiber.Web node and open FFDeploy.ps1 from the Deploy folder.

Figure 119

Opening DSC script in Visual Studio

4. 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.

Figure 120 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.

5. 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.

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 at https://msconfiggallery.cloudapp.net).

6. Note that the xWebAdministration module is included in source control within the Deploy folder. This folder is deployed with the website, and is therefore available to script that runs on the target servers during deployment.

Figure 121xWebAdministration folder deployed with website

7. Now let’s 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 122Insert Caption

8. 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 the configuration is enacted).

Figure 123DSC configuration script

Task 6: Additional Application-Specific Configuration

1. Open the web.config file from the root of the FabrikamFiber.Web project so that we can update the connection string.

Figure 124Opening web.config

2. 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.

Figure 125Viewing the connection string for the database

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

Figure 126Copying connection string for database

4. Press Escape to close the connection string dialog.

5. Select the Dashboard link and scroll down to the Quick Glance section. Locate the Server Name property and make note of it for later use. This is the fully qualified DNS name for the server.

6. Next, select the link to Manage allowed IP addresses.

7. Allow your client machine to connect to the database running in Azure by selecting the “Add to the Allowed IP Addresses” link.

8. 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 127Location to place new connection string

9. Locate the part of the connection string with the {your_password_here} placeholder and replace it with the real value.

10. Open Global.asax and comment out the call to Database.SetInitializer in Application_Start().

11. Check in your changes.

12. Now we will take a shortcut to initialize the database with the correct schema, but keep in mind that in a real-world scenario you would likely build this aspect into the deployment process itself.

13. Launch SQL Server Management Studio and connect to the default instance of SQL running locally (you can user Server Name of VSALM).

14. Expand the Databases node, right-click on FabrikamFiber-Express database, and then select Tasks | Generate Scripts.

15. In the Generate and Publish Scripts wizard, click Next.

16. Select the option to Select specific database objects, select all Tables, and then click Next.

17. Select the Save to Clipboard option and then click Next.

18. Click Next.

19. After the result is a Success, click Finish.

20. In Object Explorer, click the Connect dropdown and then select Database Engine.

21. For Server Name, enter the fully qualified name of your server running in Azure.

22. For Authentication, choose SQL Server Authentication and then enter your credentials. Refer to the connection string that you just modified in web.config if necessary.

23. Click Connect.

24. Expand the Databases node to locate your database.

25. Right-click on the database node and select New Query.

26. Press Ctrl+V to paste the clipboard data into the new query.

27. Delete the first line of the SQL script that is “USE [FabrikamFiber-Express]”.

28. Click the Execute button to run the script.

29. Return to Visual Studio.

30. Since we already have a Fabrikam Fiber build defined, let’s 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 128Editing build definition

31. In the Process tab, change the Release Build option to False (see the Release section at the bottom). We will manually create a new release later.

Figure 129Modifying build definition

32. Press Ctrl+S to save changes to the build definition.

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

34. Use the default options for the build by pressing the Queue button.

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

Task 7: Defining and Configuring the Release Template

1. Return to the Release Management client and navigate to the Configure Apps | vNext Release Templates tab and select the New button.

Figure 130Creating a new release template

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

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

4. Select the build definition for the FabrikamFiber project.

5. Select the Create button to create the release template.

Figure 131Creating a new release template

6. In the Toolbox, right-click on the Components node and select Add.

Figure 132Linking component to release template

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

Figure 133Linking component to release template

8. Drag and drop an instance of the Deploy Using PS/DSC action to the Deployment Sequence.

Figure 134Adding deployment action to deployment sequence

9. Expand the Deploy Using PS/DSC action within the Deployment Sequence.

Figure 135Adding deployment action

10. Now it is time to fill in the configuration variables for the Deploy To Azure Environment action.

11. Type the configuration variables as shown in the screenshot below, just make sure that your ServerName, UserName, Password, and ComponentName match the correct values for your setup (you can find ServerName and ComponentName specified in the Toolbox).

Figure 136Providing configuration variables

12. Select the Save button.

Figure 137Saving the new release template

Task 8: Initiating a Release to Azure

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

Figure 138Creating a new release

2. In the Properties window, select the most recent build by clicking on the Select link.

Figure 139Selecting the build to release

3. Double-click on the most recent build to select it. You may need to set the filter to be “< Any Time>”.

Figure 140Selecting the build to release

4. Select the Start button to initiate the build.

Figure 141Starting the release of Fabrikam Fiber to Azure

5. 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 haven’t been already (which will be the case on a default installation of Windows Sever).

Figure 142

Release in progress

6. After the release has completed, select the View Log link. Open the log using Notepad.

Figure 143Viewing deployment log

7. Scroll down through the log file to the section where the DSC configuration output is shown. You should see that IIS was installed, ASP.NET, and so on. Close the Notepad window.

8. Test out the release of Fabrikam Fiber to Azure by loading the URL for your Azure service in Internet Explorer. This should be the name of your environment with cloudapp.net appended. If you don’t remember the name of the service that was created for your virtual machine in Azure, return to the management portal and navigate to the Cloud Services tab -- there should be a column that contains a URL link you can click on. After a few moments, you should see the deployed Fabrikam Fiber site.

Figure 144Fabrikam Fiber running in Azure

To give feedback please write to VSKitFdbk@Microsoft.com

Copyright © 2023 by Microsoft Corporation. All rights reserved.