Donovan Brown

Technology Blog

My DSC works from PowerShell ISE but not from Release Management

06 February 2015 Donovan-Brown Work (0)
If you are like me you learned Desired State Configuration (DSC) before trying to incorporate it with Release Management.  I recommend this because you get a pure understanding of DSC and its full capabilities. The only caveat to learning DSC this way is certain things are different when used with Release Management.  One of which came up today, which is the way we identify the nodes.  Using pure DSC you have many choices on how you identify the nodes to target.  You can use Configuration Data, hardcode the values or even parameterize your DSC script.  However, I have had the most success when I use $env:COMPUTERNAME.  You could also use 'localhost'. When you learn DSC outside of Release Management you use a developer workstation to create the MOFs and push them from there to the target nodes.  However, when Release Management runs a DSC script it is first copied to the target machine.  Then the script is executed to create the MOF file to be pushed to the node.  Because the script is being copied to the target the use of $env:COMPUTERNAME eliminates the need to hardcode any values in your script and reduces the chance for error.

How to deploy the Fabriakam Call Center application with DSC

20 November 2014 Donovan-Brown Work (0)
Because there is not an Update 4 version of the Keller VM using the Visual Studio 2013 Update 3 Keller VM I will show you how to upgrade Release Management to Update 4 and create a vNext deployment for the Fabriakam Call Center application. First we have to uninstall Release Management Update 3. Log in as Brian Keller and uninstall the components in the following order: Deployer Client Server You will get an error during the uninstall of the server just click Close the program. Now download Update 4 of Release Management iso image from VisualStudio.com and mount the image to your VM. Install the components in the following order: Server: password for Administrator is P2ssw0rd  Client: enter “vsalm” for Release Management service Deployer: password for Administrator is P2ssw0rd Upgrading just Release Management to Update 4 without the rest of the system will break build. The work around is to copy Microsoft.VisualStuio.Services.Common.dll and Microsoft.VisualStuio.Services.WebApi.dll from “C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin” to “C:\Program Files\Microsoft Team Foundation Server 12.0\Tools”.  Make sure restart the build service after you copy the files. The shortcut pinned to the Taskbar for the Release Management Client will be broken so fix it to point to the next installation of Release Management. To use DSC to deploy your application you have to make sure your DSC script is in the drop location so let’s address that first.  Open the FabrikamFiber.CallCenter solution and add a Configuration folder to the FabrikamFiber.Web project. This folder will contain all the DSC scripts we need to deploy our project using DSC.  Right click on the Configuration folder and select Add / New Item.  Add a new text file named “install.ps1”.  From the Solution Explorer right click “install.ps1” and select Properties.  Change the “Copy to Output Directory” to “Copy always”.  This will ensure the file ends up in the drop location.  Enter the following text into install.ps1.  Configuration InstallWebSite { Node $env:COMPUTERNAME { WindowsFeature InstallIIS { Name = "Web-Server" } WindowsFeature AspNet45 { Name = "Web-Asp-Net45" } File CopyBits { DestinationPath = $DestinationPath SourcePath = $applicationPath Type = "Directory" Recurse = "True" } } } InstallWebSite This is the DSC configuration that will ensure that IIS and ASP.net 4.5 are installed and copy the files to the server.  The variable $DestinationPath will be defined on the component in Release Management and $applicationPath will be provided to the script from Release Management. Now check in your changes and queue a new build disabling tests. Make sure the build passes and open Release Management. The only way to add a new vNext server is by creating an Environment so let’s begin there.  Click “Configure Paths” then “Environments”. Using the new menu select “New vNext: Standard”. Enter the following values: Name: DSC-Dev Owner: Brian Keller Description: Development environment for Web Team for internal apps using DSC. Now click the Create button under the Servers Tab.  We are going to be deploying to the VM which is named VSALM.  The DNS Name must contain the port to use to establish a PowerShell Remote connection. The default port for PowerShell Remoting is 5985. Name:  VSALM DNS Name: VSALM:5985 Owner: Brian Keller Click Save & Close the Server dialog and click Save & Close on the Environment.  Repeat this process for each environment linking to the same machine. Now we have to create vNext Release Path.  Click “vNext Release Paths” then New.Name: Fabrikam Call Center DSC Description: Release path for the call center app using DSC. Add a stage. Stage: Dev Environment: DSC-Dev Automated: <Checked> Approver: Web Team Owner: Web Team Validator: Web Team Approver: Brian Keller Repeat this process for each stage of your deployment.  When you are done Save & Close the Release Path. Now move to the “Configure Apps” tab so we can configure our vNext Components on the Components tab. From the New menu select “New vNext”. Name: Fabrikam Call Center DSC Builds with application: <Checked> Path to package: _PublishedWebsites\FabrikamFiber.Web Click “Configuration Variables” tab and Add a new configuration variable. Name: DestinationPath Type: Standard Now Save & Close your component. The final step is to create a vNext Release Template. Click New on the “vNext Release Templates” tab. Name: Fabrikam Call Center DSC Description: Call Center DSC Release Path: Fabrikam Call Center DSC Build definition: vsalm:8080/FabrikamFiber/Nightly Fabrikam (Dev) Can Trigger a Release from a Build: <Checked> Click Create. Right click on Components in the Toolbox and link your component. To build your Deployment Sequence simply drag the “Deploy Using PS/DSC” on to the Deployment Sequence. Expand the action and use the following values ServerName: VSALM UserName: .\Administrator Password: P2ssw0rd ComponentName: Fabrikam Call Center DSC PSScriptPath: Configuration\install.ps1 SkipCaCheck: True Leave the rest of the values empty. Under “Custom configuration” add a new “Standard Variable” and select “DestinationPath” set the value to “c:\FabrikamRM\WebSite\DEV” (without the ""). Copy and paste the sequence to the QA stage and change the value of the DestinationPath variable to “c:\FabrikamRM\WebSite\UAT” and repeat to the Prod stage using  “c:\FabrikamRM\WebSite\PROD”. Click Save then click “New Release”. Use the latest version of the build and click Start. Good luck! If you have any questions feel free to ask me on Twitter @DonovanBrown install.ps1 (438.00 bytes)

How to Xcopy deploy using TFS 2010/2012

01 August 2011 Donovan-Brown Work (0)
Problem I need my VS2010/VS2012 build to perform an “Xcopy deployment” of my ASP.NET application to an existing virtual directory. Solution Customize the build template to use the CopyDirectory activity to copy the ASP.NET application to the virtual directory. Explanation One of the benefits of ASP.NET development is the simply “Xcopy deployment”. ASP.NET applications require no changes to the registry and have no special installation requirements for the hosting server.  Therefore, you can use the drag-and-drop feature in Microsoft Windows Explorer, File Transfer Protocol (FTP), or the DOS Xcopy command to copy files from one computer to another. The only prerequisite of this technique is the virtual directory in IIS must already be created and configured. The goal of this build is to not have to install any special features or extensions in IIS to facilitate deployment of my ASP.NET application.  I want my environments to match production as close as possible and I never intend on installing IIS Extensions in production. When you configure a build definition that builds and ASP.NET application the binaries directory and drop location contain a folder named _PublishedWebsites.  Each ASP.NET application built during the build will have a sub directory that contains all the files needed for the application. To perform an “Xcopy deployment” we simply need to identify the source and destination directories.  We are going to store this information in arguments passed to the build.  To begin open the DefaultTemplate.xaml file in VS2010 and click the Arguments button at the bottom of the workflow designer to show the workflow arguments.  Add two string arguments  VDir and SiteDir. Now let’s add a nice coat of polish on our arguments.  Click the ellipses next to the default value of the Metadata argument to show the Process Parameter Metadata Editor window.  Click the Add button and enter in the following information and click OK. Parameter Name – VDirDisplay Name – Virtual DirectoryCategory – DeployDescription – The full UNC path to the virtual directory to copy the website too. Editor – leave blankRequired – leave unchecked View this parameter when – Always show the parameter and Parameter Name – SiteDirDisplay Name – Site DirectoryCategory – DeployDescription – The sub directory of _PublishedWebsites to copy from.Editor – leave blankRequired – leave uncheckedView this parameter when – Always show the parameter   We are simply going to add a CopyDirectory activity that uses the arguments we just created to perform the copy.  To begin we must locate the correct area of the build template to add our CopyDirectory activity.  I find the quickest way to do this is to click the Collapse All button at the top of the workflow designer window.  Now double click on the words Double-click to view on all of the following activities: 1.    Run On Agent2.    Try Compile, Test, and Associate Changesets and Work Items 3.    Sequence4.    Compile, Test, and Associate Changesets and Work Items5.    Try Compile and Test6.    Compile and Test7.    For Each Configuration in BuildSettings.PlatformConfigurations8.    Compile and Test for Configuration When we configured the metadata for our arguments we left the Required checkbox unchecked.  This will allow users of this build template to leave the values for VDir and SiteDir blank if they are not building an ASP.NET application or simply do not want to deploy them.  Therefore, we need to check the value of the arguments to determine if we need to perform the copy or not.  In the toolbox expand the Control Flow tab and drag and drop the If activity right above the If Not Disable Test activity.  Click the double down arrows in the title bar of the if to show its contents. In the Condition text box enter the following: Not String.IsNullOrWhiteSpace(VDir) From the toolbox drag and drop a Sequence activity from the Control Flow tab onto the Then side of the If.  Change the DisplayName of the sequence to Deploy ASP.NET Application. We add a sequence here so that we can use multiple activities. Click the double down arrows in the title bar of the sequence to show its contents.  This is where we are going to add the activities needed to copy the ASP.NET application to the virtual directory in IIS. Now we can add the CopyDirectory activity and set the properties to deploy our ASP.NET application during the build.  To get started simply drag and drop the CopyDirectory activity from the Team Foundation Build Activities tab into the Deploy ASP.NET Application sequence.  With the CopyDirectory activity selected set the following values in the properties window: •    Destination – Vdir•    Source  - BinariesDirectory + "\_PublishedWebsites\" + SiteDir Now save your xaml file, check in your changes and queue a new build. You can download a copy of the final file below. TFS2010 DeployTemplate.xaml (55.16 kb) TFS2012 DeployTemplate.11.1.xaml (75.68 kb)