Continuous Learning and Sharing of Team Foundation Server and Application Lifecycle Management RSS 2.0
# Tuesday, December 07, 2010

Team Deploy 2010 is a custom add-on for Team Foundation Server 2010 (TFS) to deploy MSIs to servers and PCs.  The deploy activity uses an XML file to manage the servers and steps for deployment including starting/stopping services and installing/uninstalling the MSIs.  This is very effective for automated deployments in environments where automated deployments are allowed.  This however does not provide a practice run into downstream environments where automated deployments are not allowed such as Staging/Integration and Production.

An alternative to this that does offer some deployment consistencies beyond the MSI is to have Team Deploy 2010 (or Team Deploy for TFS 2008 also supports this) execute a PowerShell script to perform the deployment steps.  The advantage of this is that the PowerShell scripts can also be used to perform the manual deployments to these other environments.  This won’t work in every scenario but should in a lot.  In this post, I am going to explain how to do this.

The first thing to do is to install Team Deploy 2010.  This is free and can be downloaded at http://TeamDeploy.CodePlex.com.  The installation instructions are detailed on the site.  For this, I will assume Team Deploy 2010 is already installed.

Next open Visual Studio 2010 and create a new build definition workflow.  Create 3 arguments called RemoteExecuteFilename, TargetMachine, and RemoteCommand.

Instead of using the Deploy activity, add the RemoteExecute activity in an AgentScope container.

image

Set the properties on the RemoteExecute activity to the arguments passed in.

image

Next, set the properties that were exposed as arguments of the build definition.  For the RemoteCommand, here is where you want to specify calling PowerShell.exe and the script file that will be executed on the target machine.  One thing I have learned after taking this snapshot is that if you have a space in the path for the script than use this syntax:

PowerShell.exe –File “\\buildserver\deploy scripts\Update.ps1”

Next specify the path where the PSTools were installed and finally specify the machine that you want to run the remote script.

image

The final step is to create the deployment script.  Thanks to the power of PowerShell, these deployment scripts can perform any action.  I have created steps for starting/stoping services, applying SQL Server schema changes, search and replace strings in configuration files, etc. Essentially anything you can do in a batch file and in .NET code, can be done in PowerShell.

Here is a small sample script that I created.  I have creates some much more complicated scripts and ran them on remote machines without any issues.

"Performing removal steps..."

$servicename = "PLA"
$service = Get-Service $servicename
if($service.Status -eq "Running")
{
    "Stopping " + $servicename
    Stop-Service $servicename
}
"status=" + $service.Status
Remove-Item "c:\miketest2"
msiexec /qn /x "{26260DBA-1519-4967-9118-D827793EF3B3}"

"Removal complete.  Starting the installation steps..."

msiexec /qb! /i "\\buildserver\deploy\simple.msi"
New-Item "c:\miketest2" -type directory

"Applying SQL Server Schema changes..."
sqlcmd -S W2K8R2BOOT -E -i \\buildserver\deploy\dropaddcooltable.sql

if($service.Status -eq "Stopped")
{
    "Starting " + $servicename
    Start-Service $servicename
}

This is it. Here are also a couple things to consider. Copy MSIs, SQL Scripts, and the deployment script to a versioned folder.  The folder is the snapshot in time including the deployment file.  Keep the deployment scripts in source control.  Lastly there is a new feature in PowerShell 2.0 called PowerShell Remoting.  I have tried it, but it looks like this could also work.  It is on my list to research and I will be sure to report back when I find out more information.

Enjoy!

Mike

This was cross posted at http://www.deliveron.com/blog/post/Executing-PowerShell-Scripts-on-Remote-Machines-with-TFS-2010-and-Team-Deploy-2010.aspx on the Deliveron’s blog at http://www.deliveron.com/blog.

Tuesday, December 07, 2010 11:45:00 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
ALM | PowerShell | Team Build 2010 | Team Deploy | TFS 2010 | Visual Studio 2010

# Saturday, September 26, 2009

In Part 1: The Deployment Process Should Enforce Good Configuration Management Practices, I gave some background on my experiences and how the configuration management process has evolved and some rules and benefits to the automated deployment MSIs.

In Part 2: How to create an automated deployment MSI, I walked through the steps to create an automated deployment MSI in Visual Studio satisfying the rules from Part 1.

In Part 3, I am going to walk through the steps to install Team Deploy.  Then walk through creating a team build, configure Team Deploy, and deploy a MSI with it. 

There is also a great Screencast by Ian Ceicys walking through the entire process of installing TFS, WIX, Team Deploy and deploying a MSI.  I highly recommend watching this.

Installing PS Tools

  • Team Deploy uses the free PSExec and PSKill utilities by Sysinternals (owned by Microsoft).  PSExec allows you to remotely run any command and PSKill can kill any process on a local or remote machine.
  • Download PSTools at http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx and install to a local folder.  I also recommend renaming psexec and pskill to something like psexec2.exe.  Some anti-virus software sees these files as a risk.

 

Installing Team Deploy

  • Browse to the Team Deploy website on CodePlex at http://TeamDeploy.CodePlex.com
  • Click on the Downloads and download the TeamDeploy.MSI.
  • Run the MSI to install Team Deploy to c:\Program Files\MSBuild\TeamDeploy
  • The windows service account that runs Team Build on the build server will need to be a local administrator on all target machines.

 

Creating a Team Deploy TFS Build

  • In Team Explorer, create a new build in your Team Project by right clicking on Builds and choosing “New Build Definition”

New Build Definition

 

  • Give it a name such as “Build and Deploy”
  • Create a workspace (Cloak other folders in your project that don’t need to be part of the build. This helps the speed up your build because otherwise the server will try to get all source files in the project)
  • Leave Project File name as is but click on the “Create” button to create a new TFSBuild.proj file.
  • Next choose the solution you want to build, then the configuration type. I recommend leaving the default.
  • Choose any options that you want to enable for running tests and/or code analysis. I would recommend leaving these unchecked for now and once you verify everything is working then go back and enable the options you want.
  • In TFS 2008, you can choose retention policies. This will help prevent builds from filling up your server disk space quickly. I usually choose Keep 7 latest.
  • the next options are for the Build Defaults. Choose the appropriate build agent. If unsure, just leave the default. Then choose the share where you want to copy the staging files.
  • The last option is “Trigger”. The "build and deploy" build should be separate from the continuous integration build. I recommend leaving the default “Check-ins do not trigger a new build”.

 

Build Trigger

 

  • Finally click “OK” to create the build type.

Creating the build definition will create the TFSBuild.proj that contains the basic options that were selected in the wizard. The following steps will customize the TFSBuild.proj file created. This file is a Xml file based on MSBuild.
  • To modify the TFSBuild.proj file, located the file under Source Control -> $/YourTeamProject/TeamBuildTypes/Build and Deploy (You can also navigate directly to this file by right clicking on the build definition and choosing "View Configuration Folder".)
  • Check out and open the TFSBuild.proj file to configure it to use Team Deploy
  • Find the comment <!—Do not edit this -> and add the following line underneath the one that is already there. It should look something like the screenshot below

<Import Project="$(MSBuildExtensionsPath)\TeamDeploy\TeamDeploy.Tasks.targets" />

AddTeamDeployProject.jpg

 

Scroll to the bottom of the TFSBuild.proj file to the <PropertyGroup>. Overwrite the Property group with the following (Adjust the paths for your specific environment):

<PropertyGroup>
    <KillAppPathFilename>c:\Program Files\PSTools\pskill2.exe</KillAppPathFilename>
    <RemoteExecutePathFilename>c:\Program Files\PStools\psexec2.exe</RemoteExecutePathFilename>
  </PropertyGroup>

  <!-- Deploy MSI  -->
  <Target Name="AfterEndToEndIteration">
    <CallTarget Condition="'$(IsDesktopBuild)'!='true'" Targets="DeployMSITargetVirtuals" />
  </Target>

  <Target Name="DeployMSITargetVirtuals">
    <Deploy DeployScript="$(SolutionRoot)\..\..\Push Scripts\SampleDeploy.xml"
            KillAppPathFilename="$(KillAppPathFilename)"
            RemoteExecutePathFilename="$(RemoteExecutePathFilename)"
            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
            BuildUri="$(BuildUri)" />
  </Target>

The copied Xml in the TFSBuild.proj should look something like this

FinishedTFSBuild.jpg

  • Save and check-in the TFSBuild.proj file


The Deploy task uses a Xml Deploy Script that contains the information of what Msi(s) to deploy, additional tasks such as starting and stopping the service, and specifies the target machines. The following steps walks you through editing this file.

DeployScript.jpg

 

There are a few things to note here.

  • Team Deploy can
    • Kill 0 to many processes
    • Deploy/Uninstall 0 to many MSIs
    • Deploy MSIs to 0 to many Target Machines
  • Modify the xml appropriately for your environment. The GUID for the uninstalls are the MSI product codes. If the MSI is done correctly it will uninstall previous versions using the upgrade code, however they are usually unable to remove the same version of the MSI, this is why we have the separate step of uninstall.
  • The ExtraArgs element contains the SETUPENV variable that is used by the MSI’s custom action to copy the correct environment’s config file to the project’s. The custom action is a simple VBScript that copies the config file (not included with Team Deploy). See Part 2 for more details on creating the config files folder structure.

 

Once the TFSBuild.proj is checked in and the Deploy script is saved (or also checked in), then you can right click on the build and do a queue new build.   The MSI will be deployed to your target machine(s).

See the Troubleshooting / FAQ section of Team Deploy or contact me if you have any questions or problems.

Saturday, September 26, 2009 1:16:00 PM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
Team Build | Team Deploy | Team Foundation Server

# Wednesday, August 26, 2009

Team Deploy is a free set of custom Team Build tasks for deploying MSIs to client PCs and servers.  Team Deploy 2.1 has been released and includes a number of fixes and a couple new features.

A special thanks to Jeremy Novak for creating the new CleanupPsExec task and multiple other fixes.  Here is the list of the changes:

  • Moved Guidance and Installation from Word document to wiki site (and created a Troubleshooting section)
  • Added -accepteula to all pstools calls so it won’t display the EULA dialog the first time it runs
  • Added new CleanupPsExec task and test to clean up the PSTools service if it becomes stuck.
  • Fixed spelling error in RemoteExecute task
  • Added support to uninstalling 32bit apps on Windows 2008 64bit servers
  • Changed property declarations to be auto-implemented
  • Updated task required properties to have the Required attribute
  • Created Team Deploy Installation Screencast
  • Other misc fixes.

Team Deploy 2.1 can be found on CodePlex at http://teamdeploy.codeplex.com/.

-Mike

Wednesday, August 26, 2009 2:49:00 AM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
Team Build | Team Deploy | Team Foundation Server

# Thursday, July 30, 2009

Note:  I slightly changed the title from TFS Deployments to Deployments with TFS in case there was any confusion about whether this is about deploying TFS or doing deployments with TFS.

In Part 1: The Deployment Process Should Enforce Good Configuration Management Practices, I gave some background on my experiences and how the configuration management process has evolved and some rules and benefits to the automated deployment MSIs.

In this Part, I will walk through the steps to create an automated deployment MSI in Visual Studio 2008 satisfying the rules from Part 1.    In this example I will build the MSI for a windows service that will auto assign the username and password.

The first few steps are standard steps for building the MSI.  Then the steps get more interesting when it starts getting into to the automated deployment settings.

Step 1:  Add the Setup Project to existing solution

To add the setup project to the solution, choose “Add New Project” > Other Project Types > Setup Project.

image

 

Step 2:  Add Project Output to MSI

Add the required files for the deployment by adding the project output of the primary project.  To the project output, right click on the setup project in the solution explorer  > View > Project Output.  A dialog box similar to the one below will appear.  Verify that the windows service project is the selected project in the combo box.  Choose Primary Output and click OK.

image

 

Step 3:  Add Custom Actions

Next add the Primary output as a Custom action for the install, uninstall, etc.  To do this, right click on the Custom Actions > Add Custom Action > Application Folder > Primary Output from <your project>.

image

Step 4:  Add Installer to Windows Service project

In the Windows Service project, add an Installer class by double clicking on the Service component to view the designer.  In the Properties window (usually) at bottom right corner, there will be a link to “Add Installer” similar to the image below.  This creates the project installer class containing the service installer and the process installer.  We will be modifying these in some later steps.

image

Step 5:  Create the environment config files and folders in the windows service and add them to the MSI.

If the solution had multiple projects, I usually create a separate project for the config files.  Here I will create the folders in the same project. Create the folders and files as shown below.  Basically environment’s config file will be stored here and checked into source control.  To add these to the MSI, go to the properties of each config file and change the Build Action to Content.  Now go back to the MSI, right click on the project > Add > Project Output > Content Files to add these.

image

Step 6:  Create Custom Action to copy the selected config file to the application folder

Now that environment configs are in the ConfigFiles folder, the selected one needs to be copied to Application folder.  To do this we need to create a custom action.  This is in VBScript but eventually I want to create these custom actions as a helper class in Team Deploy.  To create the custom task, the actual file needs to be created outside the MSI.  I have created a CustomActions folder in the windows service project.   In there I added a copyconfig.vbs file.  This custom action is going to need two values passed into it.  One is the environment and the other is TargetDir.  I couldn’t figure out a way to get current folder inside for the vbscript so I found it easier to just pass it in.  To pass in values into the custom action the name/value pairs are passed into the CustomActionData property.  Also since this is going to overwrite the current app.config files, exclude the app.config by clicking on the Primary Output > Exclude > Add for *.config.

Here is the code for the copyconfig.vbs file.  After you copy and paste this into the vbs file.  Save it and in the properties, change the Build Action to None.   We do not want this copied to the MSI output like the config files. 

on error resume next
dim paramsList
paramsList = split(session.property("CustomActionData"), ",")
dim param1
dim param2

param1 = paramsList(0)
param2 = paramsList(1)

dim filesys
dim path

path = param2 & "configfiles\" & param1 & "\"

dim strEvn, objFile, strLogFile

Set objShell = CreateObject("Wscript.Shell")
strEnv = objShell.ExpandEnvironmentStrings("%temp%")
strLogFile = strEnv & "\MSIInstallLog.txt"
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile(strLogFile, 8, True)

objFSO.CopyFile path & "*.config", param2, true

if err.number > 0 then
    objFile.WriteLine Now & "::CopyConfigs - " & param1 & err.Description
else
    objFile.WriteLine Now & "::CopyConfigs - Completed Successfully."
end if

objFile.Close

Now add the Custom Action to the MSI by right clicking on the project > View > Custom Actions.  We only want this to run during the installation process, so right click on Install > Add Custom Action > Application Folder > Add File > Browse to Copyconfig.vbs and click OK.  Notice in the setup project that the copyconfig.vbs has the no sign icon on it so it isn’t copied to the application folder.

Next we need to pass in the the values into the Custom Action.  Click on the Copyconfig.vbs in the Custom Actions view.  In the properties window, set CustomActionData = [ENV],[TARGETDIR]. 

Repeat the steps above for AssignService.vbs.   Set CustomActionData = [USR],[PWD],"SampleService"

on error resume next

dim param

param = split(session.property("CustomActionData"), ",")

if len(param(0)) > 0 then

    dim strEvn, objFile, strLogFile

    Set objShell = CreateObject("Wscript.Shell")
    strEnv = objShell.ExpandEnvironmentStrings("%temp%")
    strLogFile = strEnv & "\MSIInstallLog.txt"
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set objFile = objFSO.OpenTextFile(strLogFile, 8, True)
    ' ------ SCRIPT CONFIGURATION ------
    strUser     = param(0)
    strPassword = param(1)      
    strSvcName  = cstr(replace(param(2), chr(34), ""))
    strComputer = "."    
    ' ------ END CONFIGURATION ---------
    set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    set objService = objWMI.Get("Win32_Service.Name='" & strSvcName & "'")
    intRC = objService.Change(,,,,,,strUser,strPassword)
    if intRC > 0 then
       objFile.WriteLine Now & "::" & strSvcName & " - " & "Error setting service account: " & intRC
    else
       objFile.WriteLine Now & "::" & strSvcName & " - " & "Successfully set service account"
    end if
    if err.number > 0 then
        objFile.WriteLine Now & "::" & strSvcName & " - " & err.Description
    end if
    objFile.Close

end if

This custom action finds the “SampleService” and changes the username and password.  I had to use the service name literal.  There wasn’t anything I could find where I could use a dynamic value.

Step 7:  Modify Project Installer to handle interactive and silent modes

One of the requirements is that the MSI needs to work when using the wizard and when specifying parameters when installing from the command line or remote utility.  Therefore when the user is installing the MSI through the wizard (we will create this in the next step)   it needs to prompt for the user and password.  This is accomplished by setting the service account of the installer to LocalSystem so it won’t prompt but if the username isn’t passed in it switches the service account to User.  This will then prompt the user.

To implement this, add the following code to the ProjectInstaller.

private string GetContextParameter(string key)
{
    string sValue = "";

    try
    {
        sValue = this.Context.Parameters[key].ToString();

    }
    catch
    {
        sValue = "";
    }

    return sValue;
}       

// Override the 'OnBeforeInstall' method.       
protected override void OnBeforeInstall(IDictionary savedState)
{
    try
    {
    base.OnBeforeInstall(savedState);
    string username = GetContextParameter("usr").Trim();

        if (username == "")
        {
            serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.User;
        }
    }
    catch(Exception e)
    {

  }
}

private string getvalues()
{
    string all = "";

    foreach (DictionaryEntry value in this.Context.Parameters)
    {
        all += value.Value.ToString() + ",";
    }
    return all;
}

Step 8:  Add step to wizard to specify the Environment.

In addition to prompting the user for the user and password, the MSI needs to prompt the user for the environment.  To add a form to the Wizard.  Right click on the setup project > View > User Interface.  Then right click on Start (as shown) and the click Add Dialog.  In this example we have 3 environment, so choose the RadioButtons (3 Buttons) and press Ok.

image

The Dialog window appears below the Confirm Installation box.  If you build the setup project you will notice the warning, “All custom dialogs must precede the 'Installation Folder' dialog”.  Therefore, click on the up arrow twice to move the RadioButton dialog window  above the Installation folder.  Now click on the dialog and view the Properties window.  There are several empty properties we need to set.  Set the following to something similar to these values:

  • BannerText = “Choose Environment”
  • BodyText = “Please select an environment from the list.”
  • Button1Label = “Production”
  • Button1Value = “Prod”
  • Button2Label = “Test”
  • Button2Value “Test”
  • Button3Labal = “Development”
  • Button3Value = “Dev”
  • ButtonProperty = “Env”
  • DefaultValue = “Prod”

 

Step 9:  Change build type to loose uncompressed files

The last step is to change the Package Files option under the setup project’s properties from “In setup file” to “As loose uncompressed files.  You will need to do this for each configuration in the project.

image

 

These are all of the steps.  I hope it helps.  Attached below is the sample solution with the setup project hosted on the MSDN Code Gallery.  You may use this however you would like.  Now that you know how to build the MSI, it is time to deploy it.  I will walk through that in the next post.

Sample Automated Deployment Solution for building a Windows Service MSI (22k)

The other future parts in the series will include:

  1. Building and Deploying ClickOnce applications
  2. Deploying a web application.
  3. Hopefully more!  Let me know what you would like to see.

 

Mike

Thursday, July 30, 2009 5:14:00 AM (Central Daylight Time, UTC-05:00)  #    Comments [1] -
Team Build | Team Deploy | Team Foundation Server

Visual Studio ALM MVP
Microsoft Visual Studio ALM MVP
Archive
<February 2012>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910
Blogroll
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2012
Mike Douglas
Sign In
Statistics
Total Posts: 76
This Year: 0
This Month: 0
This Week: 0
Comments: 52
All Content © 2012, Mike Douglas
DasBlog theme 'Business' created by Christoph De Baene (delarou)