Well I’m happy to say the DevOps Workbench Express Edition was in the Patterns & Practices Book that was released this morning. You can find the book here:
We were featured in the Appendix as another way to build a release pipeline with DevOps Workbench Express Edition.
Here is the link to the appendix (copy below):
This topic has not yet been rated - Rate this topic
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.
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.
This table lists the software prerequisites for the two components that make up the Express Edition, the DevOps Workbench and the Deployment Explorer.
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
Microsoft Visual Studio 2010 or 2012, Professional, Premium, Ultimate, or Test Professional
You install the Express Edition on your local machine. You will need another machine to act as the target for the deployment.
In this section you download and install the Express Edition.
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.
In this section you familiarize yourself with the DevOps Workbench user interface (UI) and learn how to create an orchestration.
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.
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.
The following screenshot shows the complete 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.
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.
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.
Enable-WSManCredSSP -Role client -DelegateComputer *
Enable-WSManCredSSP -Role server
For more information, see Enable—WSManCredSSP.
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.
This section shows you how to deploy by using the DevOps workbench.
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.
As an example, assume that the XAML deployment file is saved as "C:\XAMLFiles\MasterDeployment.xaml". Here is the correct command.
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.
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.
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.
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.
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.
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.
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: http://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 http://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 http://msdn.microsoft.com/library/dd631902.aspx.
The hands-on labs that accompany this guidance are available on the Microsoft Download Center at http://go.microsoft.com/fwlink/p/?LinkID=317536.
Next Topic | Previous Topic | Home | Community