Achieving Continuous Delivery with VSO and RMO (it is easier than you think) 14 January 2015 Donovan-Brown Work (0) Release Management Online (RMO) monitors the build definition configured to a release template. When the build is completed a release is automatically kicked off. This is a great step forward from the past where we had to use custom build templates or resort the CLI or REST API to trigger a build. This works regardless if you are using a hosted or on premises build controller. It has never been easier to achieve continuous delivery than it is today with the combination of Visual Studio Online (VSO) and RMO. Simply check a project into VSO and add a new build definition. Now in Release Management create a new Release Template associated with that build and check the box "Can Trigger a Release from a Build?" That is it! The next build will start this release. One thing I noticed was missing and the Product Team appears aware of is the inability to set a target stage. As it sits today the target stage will always be the final stage of your Release Path. That is a relatively small compromise for how easy they have made it to trigger a release from a build in VSO.
How to use VSO and RMO to deploy an Azure Website 21 November 2014 Donovan-Brown Work (0) This is a neat post because we are going to be using all three Azure offerings SaaS, PaaS and IaaS.& [More]
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)
Trigger a vNext Release from team build 18 November 2014 Donovan-Brown Work (0) Using Release Management you can implement true Continuous Delivery. With the latest update of Release Management you can trigger a release via a REST api call to Release Management. In this post I will share the script and build definition I used to trigger the release and how to use them in your team build. Although team build now allows us to run PowerShell scripts as part of our build we are still forced to create a custom build template. The reason being the two opportunities provided by the default template are at the wrong points during the build. We can run a PowerShell either before or after the build. However, we need to run a PowerShell after the drop of the files. So the attached build template adds the ability to run a PowerShell after the files are copied to the drop location. To use the ps1 and build template in your build they must be stored in TFS. So pick a location and check the files into TFS. The files do not have to be stored together. We will use these server paths when we configure our build. To create a new build definition using the build template attached just create a build like normal. Once on the Process tab select the Show details button and click the New… button. Use the Browse dialog to locate the new build template in TFS and click OK. With the Trackyon.1.0.xaml selected you will have additional features most importantly for this post the “Post-drop script arguments” and “Post-drop script path”. The value for “Post-drop script arguments” are Release Management Server name, Release Management Server Port, Team Project and Target Stage each separated by a space. For example in the image below my Release Management Server name is “DemoDC” running on port 1000, my team project is “Scrum” and I want to target the “QA” stage of my release path. The value for “Post-drop script path” is the server path to the trigger.ps1 file. Now all you have to do is start your build to have it trigger a release in Release Management Before I end this post I would like to touch on some challenges I faced with trying to use the REST api for Release Management. One issue that was very difficult to troubleshoot was the requirement that the URL of TFS configured in Release Management on the Manage TFS tab must match exactly to the URL passed in by the script. However, the value stored in $env:TF_BUILD_COLLECTIONURI used in the script is read from the Server URL in the Team Foundation Server Administration Console. If those values do not match the release will fail. You can use the Change URLs link in the Team Foundation Server Administration Console to change the Server URL so it matches the one in Release Management. Just as a tip make sure you have Fiddler installed because the error messages from the REST api or not very informative. I had to use Fiddler a couple of times to troubleshoot issues. Trigger.ps1 (2.78 kb) Trackyon.1.0.xaml (48.84 kb) (right click and Save Target As)
How to run Microsoft Test Manager Suite in vNext Deployment 18 November 2014 Donovan-Brown Work (0) While preparing to speak at TechEd Europe I really had to run Release Management and Desired State Configuration (DSC) through their paces. I already blogged about one of my challenges of implementing tokenization in a DSC based deployment here. I also wanted to run Coded UI tests as part of my release. To do this I simply ran the attached PowerShell script during my release. The script is very similar to the tool I wrote for the Agent based deployment here. In this post I simply share the ps1 file that is attached and explain how to add it to your pipeline. For this post I will be using Update 4 of Release Management. The first thing you have to do is make sure the ps1 file is in the drop location of your team build. There are several ways you can do this, however, I simply added a Configurations folder to my Coded UI Test project in Visual Studio. The most important part is to make sure that “Copy to Output Directory” is set to either “Copy if newer” or “Copy always”. This will ensure the file is in the drop location of the build. Now queue a build and examine the drop location. You will need to know the relative path from the root of the drop location of your ps1 script for use in your “Deploy Using PS/DSC” action of your vNext Release Template. Now let’s add a new vNext component in Release Management. Select the “Builds with application” radio button and simply enter a “\” for the value. On the “Configuration Variables” tab you have to setup all the parameters for the ps1 file. Add each variable as a Standard configuration variable (Collection, TeamProject, PlanId, SuiteId, ConfigId BuildDirectory, TestEnvironment, Title and TestRunWaitDelay). You can refer to my previous post on where to locate the values for each configuration variable. One of the new features of Update 4 is the ability to define default values for variables that do not change very often. As you can see in the image below I set default values for Collection, TeamProject, TestEnvironment and TestRunWaitDelay. With our component created we can move on to the vNext Release Template. Create a new one and add your components. Now drag the “Deploy Using PS/DSC” action onto the deployment sequence. Select the desired server from the ServerName dropdown. That server must already have a Test Agent configured on that machine with tcm.exe. The UserName and Password that are provided is an account that has permission to establish a Remote PowerShell connection to the target machine. Please note that in Update 3 of Release Management this is NOT the account that will execute your ps1. The ps1 in Update 3 is run by local system. Which means for this to work local system must have access to your TFS or you will get an access denied error. Select your test component in the ComponentName dropdown. Now enter the relative path to the ps1 file in the drop location. You can leave the rest of the values blank. We now have to add the Custom configuration variables to the action. Click the plus button or use the down arrow and select “Standard variable”. On the newly added row select the configuration variable you want to set and enter the correct value. For the BuildDirectory variable enter “$applicationPath”. This variable is provided by Release Management and points to a location that contains the files of our component. Now you should be able to run a new release and execute automated test. RunTests.ps1 (4.94 kb)
Release Management Error - Permission denied while trying to connect to the target machine 06 October 2014 Donovan-Brown Work (0) Problem: I get the following error when I attempt a DSC release with Release Management: Permission denied while trying to connect to the target machine Demo on the port:5985 via power shell remoting. Solution: Don't overlook the obvious. Triple check the password of the account in the "Deploy To Standard Environment" activity. The account used here must have permission to connect via power shell remoting. If that fails try adding the source to the TrustedHosts of the remote machine. You can read how here http://technet.microsoft.com/en-us/library/hh847850.aspx.
Reschedule a defered release 30 September 2014 Donovan-Brown Work (0) Problem: I accepted a release and deferred the deployment to a later date but now I want to change the date of the release. Solution: You have two options. If you simply want to release the code now you can click the Allow Deployment Now button on the release's log page. If you want to change the date of the release simply click the Properties link and adjust the time and save your changes.
Missing WinRMPort in Server DNSName xxx 25 September 2014 Donovan-Brown Work (0) Problem From Release Management I am getting the following error when I attempt a DSC deployment “Missing WinRMPort in Server DNSName xxx” Solution Make sure and include the port when adding a server to your environment.
Tokenization for DSC 05 September 2014 Donovan-Brown Work (0) Update! This resources has been officially release by Microsoft here http://tinyurl.com/xReleaseManagement Update 3 of Release Management introduced Desired State Configuration (DSC) as a deployment option in addition to the deployer based solution. With DSC we can utilized the Local Configuration Manager (LCM) already installed on many Microsoft operating systems to deploy our applications without the need to install prerequisites. However, I noticed after playing with it for a while that there was no mechanism to tokenize files for transformation. This is a requirement for applications that store configuration information in web.config or app.config files. This data needs to be updated as the code is promoted from one environment to the next. I set out to fill this gap by writing a custom resource to transform the files as we can with the deployer based option of Release Management. Attached to this post is a zip file that contains custom Windows PowerShell Cmdlets, custom DSC Resource and a sample configuration that shows how to use them. The xReleaseManagement folder contains the implementation of the Trackyon_xTokenize resource to be used in your configurations. This resource requires the Write-Token and Test-Token Cmdlets provided in the Trackyon.PowerShell.ReleaseManagement.Module module also in the attached zip. Finally in the zip file are to ps1 files with a sample configuration and start-dscconfiguration calls. All of the Cmdlets, resources and tools are provided AS IS, and are not supported through any support program or service. xReleaseManagement.zip (15.90 kb)
Speaking at Dog Food Conference 2014 24 August 2014 Donovan-Brown Work (0) If you don't have a chance to see me at TechEd Europe or St. Louis Days of .NET I will also be speaking at Dog Food Conference 2014. Cross-Platform Development with Team Foundation Server 2013 This session provides an overview of how cross-platform teams can utilize the power of Team Foundation Server (TFS). The power of TFS can be leveraged by developers of any language and platform. We will demonstrate how to use and access TFS from Eclipse and deploy to Linux with continuous Deployment.