Hands-On Lab. Embracing Continuous Delivery with Release Management for Visual Studio Lab version: Last updated: 12/11/2013

Transcription

1 Hands-On Lab Embracing Continuous Delivery with Release Management for Visual Studio 2013 Lab version: Last updated: 12/11/2013

2 CONTENTS OVERVIEW... 3 EXERCISE 1: RELEASE MANAGEMENT OVERVIEW... 4 EXERCISE 2: CONFIGURING RELEASE MANAGEMENT EXERCISE 3: DEFINING A RELEASE PATH AND TEMPLATE EXERCISE 4: RELEASE AUTOMATION EXAMPLE... 30

3 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 the cloud. 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 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 onpremises 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

4 3. Defining a Release Path and Template 4. Release Automation Example 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 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 1 Release Management components

5 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 webclient designed for testers, user acceptance approvers and managers. Release Management Deployer. The deployer 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 Deployer. Deployer 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. 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 The deployers (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 to Note that we do not currently have any pending approval requests.

6 Figure 2 Release Management web application 6. Select the Previously Approved link and note that there was a release triggered by a build of the Fabrikam Call Center. Figure 3 Viewing previous approvals 7. Select the link displaying the number of deployed components (just underneath the name Brian Keller). Figure 4

7 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 Escape key to close the dialog window. 10. 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 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.

8 Figure 7 Prod stage historical workflow 12. Select the Previous Stage link. Figure 8

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

10 Figure 10 Dev stage historical workflow 15. Press the Escape key 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. 17. The Release Management Deployer 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 Deployer 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 Deployer 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

11 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 Deployer services, the configuration of groups and users, and finally the configuration of servers and environments. 1. Launch the Release Management client from the taskbar. Figure 11 Release 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 12 Traffic overview

12 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 13 TFS connection configuration 4. Double-click on the TFS connection that has already been setup. Figure 14 Loading 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 15 Configuring account to connect to TFS 6. Other important settings can be configured in Administration System 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.

13 Figure 16 System 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 deployer services to poll the Release Management server for packages to deploy. Figure 17 Deployer settings 8. Let s take a quick look at the setup of users and groups for Release Management. Navigate to Administration Manage Users.

14 Figure 18 User configuration 9. Double-click on the Brian Keller user. Figure 19 Viewing user configuration details 10. 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 20 Viewing user configuration details 11. Navigate to Administration Manage Groups to take a quick look at how groups can be setup.

15 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 Refresh button) unless the setting AD/TFS-Based Group Refresh Interval is setup to something other than 0 minutes (which is the default). 13. Double-click on the QA Team. Figure 23 Viewing group details

16 14. 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 24 Viewing group members 15. Select the Security tab. Figure 25 Location of Security tab 16. 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 26 Group security settings 17. 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.

17 Figure 27 Configuring stage types 18. Servers to be used for deployment must have the Release Management Deployer 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 Deployer service has already been setup and configured for this virtual machine. Figure 28 Configuring 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 New. 19. Double-click on the VSALM server.

18 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. Figure 31 Viewing environment configuration

19 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-click on the first environment named Int-Dev. Figure 32 Viewing environment configuration 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 Security tab. Figure 33 Viewing 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. 1. Now let s look at a release path definition. Navigate to Configure Paths Release Paths and double-click on the Fabrikam Call Center release path.

20 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 3. Now let s look at how the Fabrikam Fiber team defined the process used to deploy their web application. Navigate to Configure Apps Release Templates and then double-click on the Fabrikam Call Center template.

21 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 Properties link. 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 Figure 38 Viewing release template properties 6. Press the Escape 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 39 Location 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.

23 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 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 41

24 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 42 Remove 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 43 Copy File or Folder node 12. Expand the Call Center Site node. Note the puzzle piece icon on the top-left, which indicates that it is an instance of a custom component. Figure 44 Call Center Site node 13. Let s look at this component by navigating to Configure Apps Components and then doubleclicking on the Call Center Site component.

25 Figure 45 Viewing custom component configuration 14. 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 46 Viewing custom component configuration 15. Select the Deployment tab.

26 Figure 47 Location of Deployment tab 16. 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 48 Viewing custom component configuration 17. Return to the Fabrikam Call Center release template and expand the Create Web Site node. This creates the specified site in IIS. Figure 49 Create Web Site node

27 18. Finally, look at the Rollback sequence, 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 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, let s take a peek at the available tools and actions. Navigate to Inventory Tools.

29 Figure 52 Location 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 Actions tab. 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 Figure 54 Viewing available actions 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. 1. Log in as Brian Keller (VSALM\Brian). All user passwords are P2ssw0rd. 2. Launch Visual Studio 2013 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.

31 Figure 55 Team Explorer Home view 3. Select the Builds tile. Figure 56 Location of Builds tile 4. Right-click on the Nightly Fabrikam (Dev) build definition and select the Edit Build Definition option. Figure 57 Editing build definition 5. Select the Trigger tab.

32 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. 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 59 Selecting Continuous Integration option 7. Select the Process tab.

33 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.xaml template is selected. Figure 61 Custom build process template Note: The Release Management build process template can be found in the \Microsoft Visual Studio 12.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

34 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 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 63 Location 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. 13. In Team Explorer Home, double-click on the first FabrikamFiber.CallCenter.sln solution.

35 Figure 64 Loading FabrikamFiber solution 14. 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 65 Location of Fabrikam Fiber link (development) 15. 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.

36 Figure 66 Location 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

37 17. In Team Explorer Pending Changes, select the Check In button. Select Yes if prompted to save changes and check in. Figure 68 Checking in change 18. If you quickly open Team Explorer Builds, you should see that the check in triggered a build. Double-click on the build. Figure 69 Opening build in progress 19. Wait for the build to finish and then select the View Log link.

38 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 Management desktop client and navigate to Releases Traffic Overview.

39 Figure 72 Loading Release Management traffic overview 22. Note that the Fabrikam Call Center release path now shows that another deployment is in process in the development stage. Figure 73 Traffic overview showing release in process 23. Double-click on the Dev stage for the Fabrikam Call Center release path.

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

41 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 alerting him about the pending approval. 27. Select the My Approval Requests link to view pending approvals. Figure 77 Location of My Approval Requests 28. Double-click on the pending approval.

42 Figure 78 Loading pending approval details 29. Select the View Sequence link. 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

43 Deployment sequence showing parameters 31. Select the View Log link. 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 Deploy step also has additional details select 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 Log link for the Remove Web Site action. Use Notepad if prompted. Figure 83 Viewing action log

44 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. Close the Notepad window and the Deployment Log window. 36. 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 85 Location of FF DEV link 37. Here we can see that Support v2.0 shows up as expected.

45 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 Approve button. Figure 87 Approving the release to the development stage 39. In the Approval Confirmation window, enter a comment such as Dev deployment looks good and then select the OK button. 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. Refresh the My Approval Requests view until the release stops for QA approval.

46 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 favorite link in Internet Explorer. Figure 90 Deployment to the QA environment is a success 42. Back in Release Management, navigate to the My Approval Requests view, select the deployment, and then select the Approve button. Figure 91 Approving the release to the QA stage 43. In the Approval Confirmation window, enter a comment such as QA deployment looks good and then select the OK button.

47 Figure 92 Adding an approval confirmation comment 44. 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 93 Prod stage workflow configuration 45. 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

48 approve the deployment to production since the QA Team signed off on the previous stage. Select the Approve button. Figure 94 Approve the request to deploy to production 46. 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 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 is deployed (displaying Support v2.0 ). Figure 96 Deployment to the production environment is a success

49 48. The Ops Team now needs to validate the deployment. Select the request and then select the Approve button. Figure 97 Approving the deployment to production 49. 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 98 Approve the deployment to production 50. 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 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, 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.

50 52. Select the New button in the Releases tab. Figure 100 Location of New button 53. 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 101 Manually triggering a release 54. In the Search Builds window, select the oldest build. Figure 102 Selecting a build 55. To start the release, select the Start button (optional).

51 Figure 103 Location of Start button 56. If you followed 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 To give feedback please write to Copyright 2014 by Microsoft Corporation. All rights reserved.