Appendix 1: DevOps Deployment Workbench Express Edition

This appendix discusses the DevOps Deployment Workbench Express Edition (Express Edition). The tool allows you to use a single build and deploy it to many different environments. In other words, in keeping with the best practices for continuous delivery, the workbench allows you to build once and deploy anywhere. The Express Edition accomplishes this by making it easy both to create deployment processes, called orchestrations, and to monitor and manage your deployments. The tool has two components. The DevOps Workbench provides XAML workflow items that you use to create the orchestrations. Similar to the workflow designer in Microsoft Visual Studio, you select items from a toolbox and drag them to a design surface. When deployment processes exist as code rather than as documents, they become versionable, repeatable, and predictable.

The second component, Deployment Explorer, is similar to Build Explorer and is available from the Team Explorer tab in Visual Studio. With Deployment Explorer you can manage deployments and review the results of completed deployments.

Here are the major subjects covered in this appendix.

• Installing the Express Edition. This section includes the prerequisites and the installation procedure.
• Constructing an Orchestration. This section first shows you how to use the workbench to create a simple orchestration and then shows you how to add complexity to the orchestration.
• Deploying a Build. This section shows you how to deploy a build by using the workbench, the command line, or Deployment Explorer.
• Using DevOps Workbench to Build Once, Deploy Anywhere. This section shows you how the workbench can help you implement a continuous delivery release process.

Installing the Express Edition

This section includes the software and hardware prerequisites for installing the Express Edition as well as the instructions for installing it on your local machine.

Software Prerequisites

This table lists the software prerequisites for the two components that make up the Express Edition, the DevOps Workbench and the Deployment Explorer.

Component	Software
DevOps Workbench	Windows Server 2008 R2, Windows Enterprise R2 64 bit (IIS installed), Windows Server 2012, Windows 7, Windows 8 or Windows 8.1
	Team Foundation Server 2010 or 2012
	Build controller
	Build agent
Deployment Explorer	Microsoft Visual Studio 2010 or 2012, Professional, Premium, Ultimate, or Test Professional

Hardware Prerequisites

You install the Express Edition on your local machine. You will need another machine to act as the target for the deployment.

Installing the Express Edition

In this section you download and install the Express Edition.

1. Download the Express Edition zip file from the Visual Studio ALM Rangers CodePlex site to a location on your local machine.
2. Open the zip file. You should see the following files.
   • DevOps Deployment Workbench Express MSI
     • Workbench
     • Deployment Explorer
     • WFExecute.exe
   • HOL folder
   • Guidance folder
3. Select the DevOpsDeploymentExpress.msi file. Follow the steps in the Install Wizard.

Creating Repeatable Builds

A build should be a repeatable, reliable process. It produces a set of binaries that have been validated by a series of tests, and that is documented by a build record in Team Foundation Server. The Express Edition requires that there is a single build that has been validated to run correctly, and that is in a secure drop location. The tool retrieves the build and then deploys it, using the steps in the orchestration, to the target environments.

To learn more about how to create builds, see the information in the guidance folder that is included in the DevOps Workbench download, or see the Team Foundation Build Customization Guide for more information on creating reusable build definitions.

Constructing an Orchestration

In this section you familiarize yourself with the DevOps Workbench user interface (UI) and learn how to create an orchestration.

Understanding the DevOps Workbench UI

The DevOps Workbench UI has three areas (numbers refer to the numbers shown in the screenshot). The Deployment Toolbox (1) contains all the items that you need to construct an orchestration. The central section (2) is the design surface where you drag deployment templates and components to construct the orchestration. The Properties area (3) allows you to view and modify the properties of the items that comprise the orchestration. The following screenshot shows the DevOps Workbench UI.

Creating an Orchestration

In this section you learn how to create an orchestration. You’ll need one orchestration per server that you'll deploy to by using the Express Edition.

1. Open Express Edition. Click File. Click New Orchestration (Ctrl + N).
2. From the Toolbox, from the Environment Verification section, select the CheckOSName activity and place it in the MasterDeploy sequence, which is on the design surface by default. The CheckOSName activity verifies that the target machine exists and ensures that the appropriate operating system is installed.
3. Select the DefaultDeployWebsite activity and place it after the CheckOSName activity.
4. Close and save the orchestration XAML File.

The following screenshot shows the complete orchestration.

Adding Items to an Orchestration

You can add as many items as you need to your orchestration in order to configure the servers you’re deploying to, and to install the prerequisites that your application depends upon.

The following orchestration expands on the previous example. It deploys a website, Microsoft SQL Server, and some test cases that will run on the target machine after the deployment is complete.

Within the Master Deploy Sequence, the Website item includes an activity that first checks that the operating system of the target machine is the correct version. The orchestration then deploys the website. Next, the SQL Server item first verifies that the operating system is the correct version and then installs and configures SQL Server on the target machine. Finally, some validation tests run to ensure that the deployment succeeded. The following screenshot shows the completed orchestration.

Properties

Each of the items that comprise an orchestration has properties that need to be defined. Some of them are required, while others are optional. You can hover over an element to see its tooltip, or you can read the ALM Rangers DevOps Quick Reference Guide to get more information and the syntax for each item.

As an example, select CheckOSName. You can see its properties in the Properties area, as shown in the following screenshot.

One of the properties is Ignore Deployment Errors. Clear this option if you do not want to ignore the errors. If you want to log any deployment exceptions, select Log Deployment Exceptions. After updating the properties, save the orchestration XAML file.

Enabling the Credential Security Support Provider

Because the Express Edition uses remote PowerShell, it can double hop from the local machine to the target machine. This means that the credential security support provider (CredSSP) must be ON, on both the server and the client.

1. Open a Windows PowerShell prompt. To enable the client-side CredSSP, enter the following command.

   Enable-WSManCredSSP -Role client -DelegateComputer *
   

2. To enable the server-side CredSSP, enter the following command.

   Enable-WSManCredSSP -Role server
   

For more information, see Enable—WSManCredSSP.

Deploying a Build

There are three ways to deploy a build. One is to use the DevOps Workbench, another is to use the command line, and the third is to use Deployment Explorer.

Deploying by Using the DevOps Workbench

This section shows you how to deploy by using the DevOps workbench.

1. Make sure you're connected to TFS. Click Source Control. Click Change Connection.

   

2. You should see a Connected to message in the lower right hand corner of the screen. The following screenshot shows an example.

   

3. From the Tools menu, click Target Servers (Ctrl + Shift + S). The View Target Servers dialog box appears. Click Add. Enter the server name, the IP Address, the user name and the password.

   

4. Click OK. Click Refresh. The View Target Servers dialog box reappears. The new server is included in the target server list. The following screenshot shows an example.

   

5. Click Close.

6. From the Tools menu, select Deploy to Server. The following screenshot shows an example.

   

7. The Deploy Package To Server dialog box appears. In the Package Name text box, enter a package name.

8. In the Package Xaml text box, enter the name of the orchestration XAML file that you saved in "Creating an Orchestration."

9. In the Target Server text box, enter the name of the target server that you connected to in step 1. If you want to use the IP address of that server instead, select that option and enter the IP address in the Target Server text box.

10. In the Target Build text box, browse to the location of the build in TFS that you want to deploy. The following screenshot shows a completed example.

    

11. Click Start. The DevOps Workbench executes the deployment by using remote PowerShell to access the target machine, where it will run each of the orchestration steps that you created. The following screenshot shows an example of a deployment that is in progress.

    

12. When the deployment completes you will get a message saying that the deployment was successful (or not), and a log file that contains your results appears.

Deploying by Using the Command Line

If you don’t want to rely on the DevOps Workbench UI to deploy your application, then you can use the command line and the WFExecute.exe file, which is in the installation directory, to execute the XAML file that you created.

To use WFExecute, you need to know the syntax.

• All the command line tasks are parsed and have the following key/value pair for the designated parameter name: <<Parametername>>:<<Propertyname>>=<<Propertyvalue>> (no spaces).
• Currently there are only two designators possible for Parametername. The designator can be either '/p' or '/source'. For the source Propertyname there are only two valid values. One is file and the other is assembly.

As an example, assume that the XAML deployment file is saved as "C:\XAMLFiles\MasterDeployment.xaml". Here is the correct command.

WFExecute.exe "/source:file=C:\XAMLFiles\MasterDeployment.xaml"

Note

You must use the fully qualified path of the XAML file that you saved.

If you want to deploy a particular assembly, you can use WFExecute to deploy just the assembly and activity that you want. Here is the syntax for the command line.

WFExecute.exe"/source:assembly=Fullyqualifiedpathtoassembly" "/p:activity=nameofactivityinassembly"

Note

You must specify all the arguments for the assembly. The format is "/p:[argumentname]=value". If you need to find out what the arguments are you can either look in the guidance at the ALM Rangers DevOps Tooling and Guidance or look at the assembly's properties by using Deployment Explorer.

Deploying by Using Deployment Explorer

Using Deployment Explorer to deploy a build is similar to using the Team Explorer Builds menu. To access Deployment Explorer, open Visual Studio. Select Team Explorer. You will see that there is a new selection available named Deployments. Similar to the standard Builds selection, Deployments allows you to manage and organize your deployments.

The following screenshot shows the Team Explorer window when Deployment Explorer is installed.

To use Deployment Explorer, simply click Deployments. You will see your recent deployments. The following screenshot shows an example.

From Deployment Explorer, you can select a particular deployment to see details about it and to see the deployment log files. If you need to return to the DevOps Workbench, perhaps to fix some errors or to improve the orchestration, click Launch Workbench, under Deployments.

Using the DevOps Workbench to Build Once, Deploy Anywhere

The guidance that accompanies Express Edition will help you to understand how to incorporate DevOps principles into a continuous delivery release process. You can download the ALM Ranger DevOps Deployment poster, which illustrates the DevOps approach.

Creating Suitable Builds

In order to take full advantage of the Express Edition, you should create builds that conform to best practices for continuous delivery. The goal is to build only once, and to deploy the same binaries to all your environments. A single build ensures that the build you tested in all the stages of the release pipeline is the build that is deployed to your customers. This is called build integrity. As has been shown in the rest of this guidance, separate builds for each environment can cause many problems.

One way to ensure build integrity is to lock the build share down by making it read only and to give write permission only to the build account. This practice guarantees that all changes are in source control, and that no one can circumvent the rules by adding unauthorized changes to the code or to the configuration.

You might consider using gated check-ins, which ensure that only code that meets the automated verification steps included in the build process is committed. Another approach, which is used in the HOLs for this guidance, is to use continuous integration as the trigger. What is important is that you receive immediate feedback on whether the build was successful or not.

Creating build definitions that conform to patterns and best practices and having a regular build schedule gives you confidence that the builds will either compile or be straightforward to fix, that successful builds will be in a secure drop location, that the builds are clearly identified and can be traced back to the source, and that other stages will always use the authorized build and not create builds of their own.

Using the Express Edition to Manage Deployments

As you've seen, the Express Edition can help you to conform to the best practices for continuous delivery. For example, using the tool ensures that you use the same binary to deploy to multiple environments because you can only retrieve the build from the drop location. It also creates standard ways to deploy to different environments, such as a website, SQL Server or Windows Azure. Again, as you've seen in the rest of this guidance, standardized deployments that ensure that the environments are automatically configured correctly get rid of many of the problems that make releases to production so difficult.

More Information

There are a number of resources listed in text throughout the book. These resources will provide additional background, bring you up to speed on various technologies, and so forth. For your convenience, there is a bibliography online that contains all the links so that these resources are just a click away. You can find the bibliography at: https://msdn.microsoft.com/library/dn449954.aspx.

ALM Rangers DevOps Tooling and Guidance at https://vsardevops.codeplex.com/.

Team Foundation Build Customization Guide at http://vsarbuildguide.codeplex.com/.

Visual Studio ALM Rangers Solutions Catalogue at https://aka.ms/vsarsolutions.

Visual Studio ALM Rangers Visual Studio Lab Management Guide at http://vsarlabman.codeplex.com/.

Installing Team Foundation Server and Visual Studio ALM at https://msdn.microsoft.com/library/dd631902.aspx.

The hands-on labs that accompany this guidance are available on the Microsoft Download Center at https://go.microsoft.com/fwlink/p/?LinkID=317536.

Next Topic | Previous Topic | Home | Community