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 1
Release 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 2
Viewing previous approvals

3. Select the link displaying the number of deployed components (just underneath the name Brian
Keller).
 Figure 3
Location 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 4
Viewing 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 5
Location 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,