The Visual Studio ALM Rangers just released two projects, the Build Customization Guide and the Lab Management Guide.  Both projects provide real world, in-depth guidance and hands-on-labs (HOL) for planning and creating solutions for utilizing the Team Build 2010 and Visual Studio 2010 Lab Management.  Every development team should utilize the features covered in these guides for creating a build strategy that includes Continuous Integration (CI), packaging and versioning of applications, and automated deployments to at least the development and test environments. By utilizing Visual Studio Lab Management, these environments can be quickly provisioned and managed by those development teams.  They will be able to do things restore to a baseline before building, deploying, and running tests in those environments, clone the environment to provide multiple test environments for QA, and attaching a snapshot of the virtual environment along with other rich information to bugs for the developers.

Visit the websites for all of the details and downloads for the guidance.

Build Customization Guide

I am especially excited about the Build Customization Guide being released because this was first Visual Studio Ranger project I have had worked on.  I had the opportunity to work with many talented and dedicated individuals.

The Epics included in this guidance are:

• Practical guidance and tooling to simplify the customization of Team Foundation Build
• Practical guidance to use Team Foundation Build process templates to automate build and non-build scenarios in Microsoft environments
• Practical guidance to enable simple and flexible deployment of applications and their data stores
• Practical guidance for Activities to empower developers and build engineers
• Quality hands-on labs that complement the guidance and effectively guide the user through the features
• Visualization of the guidance using quick reference posters

http://rabcg.codeplex.com/

Lab Management Guide

I didn’t contribute to the Lab Management Guide, but I have read through the guidance.  It includes a lot of great information that include planning Lab Management, setting up the Virtual Lab environment, and creating Virtual Machines using the VM Factory.

The Epics included in this guidance are:

• Visualization of the guidance using quick reference posters
• Advanced golden image management using the VM Factory for Lab Management
• Provide guidance on setting up Test environments with respect to pre-defined personas
• Provide Guidance to enable large and small teams to setup and configure both automated and manual tests
• Provide practical guidance for managing and maintaining a Lab Management environment
• Provide practical guidance to enable teams to quickly setup and configure their lab management environment

http://ralabman.codeplex.com/

Visual Studio ALM Rangers

So who are the the Visual Studio ALM Rangers?  They are a group of internal Microsoft employees and external communities leaders/MVPs who’s mission is to accelerate the adoption of Visual Studio with out-of-band solutions for missing features and guidance.  Willy-P. Schaub has posted some great information about who we are, the past accomplishments, and future plan in the Visual Studio ALM Rangers 5 year Report.

Please contact us at tfs@deliveron.com for information on these guides or implementing these solutions in your environment.

Mike

The Nebraska Code Camp is a free, community-driven conference.  Attend the Nebraska Code Camp on April 9th, 2011 in Lincoln, NE.  Includes 25 sessions from local and regional speakers on topics including Windows Phone 7, BDD, ALM, WCF, MEF, JQuery, and Cloud Computing.  I am fortunate enough to giving two talks on Visual Studio 2010 ALM including Getting Agile with Visual Studio 2010 and Coded UI Tests Deep Dive.

Take a look at all of the Sessions and Speakers at this great event.

Register today.  Did I mention it is FREE??!!!  I hope to see you all there.

Follow Nebraska Code Camp on Twitter

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.

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

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.

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.

Coded UI Tests do a great job of capturing the action recordings of the steps performed in a test case. The action recordings are used to create the automated code to test the actions.  Unfortunately sometimes these steps are too literal and become excessive especially when running the tests using multiple rows of parameters (that are essentially data driven tests) 

In my example, I created a test case that lists some steps that include opening the application, adding a new customer record, and closing the application.   The application allows for creating multiple customer records without closing and reopening the application.  Closing and reopening the application for each row in the automated test is unnecessary.  Shared steps at the beginning or ending of the tests including logging in/out could be good candidates to make more efficient.

Below is the example of the test that was generated from the action recordings of the test case.

        [DataSource("Microsoft.VisualStudio.TestTools.DataSource.TestCase", 
                 "http://localhost:8080/tfs/defaultcollection;Tailspin Toys", "53", 
                 DataAccessMethod.Sequential), TestMethod]
        public void AddCustomer_ShouldSaveAndClose()
        {
            // To generate code for this test, select "Generate Code for Coded UI Test" 
            // from the shortcut menu and select one of the menu items.
            // For more information on generated code, 
            // see http://go.microsoft.com/fwlink/?LinkId=179463
            this.UIMap.OpenCustomerKeeper();
            this.UIMap.OpenNewRecord();
            this.UIMap.FillParams.UIText1EditText = TestContext.DataRow["Name"].ToString();
            this.UIMap.FillParams.UIText2EditText = TestContext.DataRow["City"].ToString();
            this.UIMap.FillParams.UIText3EditText = TestContext.DataRow["Phone"].ToString();
            this.UIMap.FilloutNameCityandPhone();
            this.UIMap.SaveandClose();
            this.UIMap.VerifyCustomerSaved();
            this.UIMap.CloseApplication();

        }

As you can see it generated the OpenCustomerKeeper() and CloseApplication() methods.  For each parameters row for the test case it will open and close the application.  These are the two methods I only want to execute at the start of the test run and the end of the test run.  Also if I had other tests that could be run without restarting the application this change would benefit those tests also.

Our options are to move these steps to the TestInitialize/TestCleanup or ClassInitialize/ClassCleanup. The TestInitialize/TestCleanup however is called before each test that also includes before each row of the data driven test.  Therefore, this would be the same result and open/close the application before each row.  This leaves the ClassInitialize/ClassCleanup.   Unfortunately it is not quite as easy as moving the method.  First these two methods need to be static so this.UIMap won’t exist.  Secondly, the Playback engine is not initialized in these methods.  We will need to explicitly perform the Initialize and Cleanup of the Playback engine.  Lastly the ClassInitialize attribute has to be applied to a method with passes in the TestContext as a parameter.

Here is the ClassInitialize method

static private UIMap sharedTest = new UIMap(); 

        [ClassInitialize] 
        static public void ClassInit(TestContext context) 
        { 
            Playback.Initialize(); 
            try 
            { 
                sharedTest.OpenCustomerKeeper(); 

            } 
            finally 
            { 
                Playback.Cleanup(); 
            } 

        }

 

Lastly, we will move the CloseApplication() method to the ClassCleanup method.

[ClassCleanup] 
static public void ClassCleanup() 
{ 
    Playback.Initialize(); 
    try 
    { 

        sharedTest.CloseApplication(); 
    } 
    finally 
    { 
        Playback.Cleanup(); 
    } 
}

 

I hope you find this useful.

Mike

Contact us at tfs@deliveron.com to work with your development teams for all of your Visual Studio ALM needs.

In one of my previous posts, I talked about Setting up a Build Server to run Coded UI Tests.  In this post I am going to talk about creating a Coded UI Test and running it from Microsoft Test Manager.   This completes the full testing story.  The build server can run the regression tests and the tests can run any automated test from Microsoft Test Manager on demand.

Create Test Case

First, create the Test Case in Microsoft Test Manager.  This is a simple test that opens the application and customer form.  Then it enters some information to the form, saves, and closes the form.

‘

Next, in MTM, go to the Test Tab and Run the test.  Microsoft Test Runner should open.  Check the Create/Overwrite action recording checkbox and click Start Test.

Finish going through the test. Be sure to be on the appropriate step of the test case when you perform the step in the application. It is capturing all of clicks to the particular step that is selected. Save and Close the test. Make sure to save the action recording.

Switch your hat to the Developer cap. Open Visual Studio 2010 Premium or Ultimate. Create a new test project. To create a new Coded UI Test, right click on the project and choose Add > Coded UI Test. A dialog appears to choose either Record actions or Use an existing action recording.

Since we already have the action recording, choose the “Use an existing action recording.” Search for the Test Case of the test that you just ran. When you click Ok, it will generate the code for the test. Run the test in Visual Studio and make sure the test passes. You will need to make sure the application you are testing is installed on your development machine.

Once you verify the test is passing in Visual Studio, you can associate the automated test back to the test case. To do this, display the Test View window by going to Test > Windows > Test View. Right click on the test and choose “Associate Test to Test Case”

 

Find the Test Case and choose Ok. This will open the test case work item. Notice that the test is now associated with the test case.

Also the Automation Status has been changed to Automated. Another thing is that the Automated test type shows “CodedUITest.” In addition to Coded UI Tests, Unit tests can be linked to a Test Case. This is very useful when you are using the unit test framework to do system level or end to end tests that would be at the same level as the Test Case.

Creating the Test Environment

Now that we have the test case automated, we need to configure the test environment before we can run it.

Test Server

First choose a machine that where the tests will run.  This can be a physical/virtual server or PC depending on the requirements of the application you are testing.  On this machine, I installed the Visual Studio 2010 Test Controller and Visual Studio 2010 Test Agent.  These could also be installed on separate machines.  A test controller can support multiple test agent machines.

To install the Test Controller and Test Agent, download the Visual Studio 2010 Agents ISO. This contains the Test Controller, Test Agent, and Lab Agent.

First install the Test Controller.  I always recommend using a domain account instead of the Network Service account.  Register the Test Controller with the Team Project Collection.  As it states, you must do this to create enable the test environment.

Once the Test Controller is configured, install the Test Agent.   I also recommend using a domain account for the Test Agent.  Configure the Test Agent to interact with the desktop.  For the Coded UI Tests to run, they must be able to have full access to the desktop.  This also means that the computer must be logged in and can’t be locked.  Make sure to check the option to disable the screen saver and to log in automatically.

Also, one thing that I have learned is you can’t use Remote Desktop (RDP) to access the test machines.  Logging out of RDP automatically locks the machine.  If the machines are virtual then you need to use access them through the virtual machine host or another remote technology.

One optional item you can configure is to configure the test machine to record video. To do this follow these steps:

1.  Install the RTM update for Lab Managementon the server

2.  Install Encoder 4

3. If the machine is a server, install the Desktop Experience feature.

Configure the Environment

The test machine is now configured.  Now we need to configure the test environment so that the automated test knows where to run.

Switch back to Microsoft Test Manager.  Change Testing Center to Lab Center by selecting it from the drop down.

First we need to create the environment.  If Lab Management was installed and configured, we could configure a virtual environment.  But since we have already configured a machine outside of Lab Management it will be considered a physical environment.

Select the Lab tab and choose New > New Physical Environment.

Fill in the Name and Description.  Choose the Test Controller to where the environment is going to be created.  Optionally, you can tag the environment.  This could be helpful if you have multiple environments with different configurations.

Next select the machine from the available machines and assign it a role.

In a physical environment there isn’t anything to set in the machine properties.  If it was virtual environment, you could specify the memory, product key, and other settings to configure the machine.  Click on Finish to create the environment.

Next is to create the Test Settings that can be used to specify what kind of testing diagnostics to capture for each machine in the environment.  In our example, we only have the one machine.  Select the Test Settings tab and click on New.

Give it a name.  Usually name this in relation to how much diagnostic data you want to capture.  Consider having a “Full” setting that has all or most of the diagnostics enabled and then another setting called “Light” or “Minimum”.

Select the Roles Tab.  Make sure the machine is set to the appropriate role and is matched to the environment.

In the Data and Diagnostics, select any of the data you want to capture while you are testing.   If your application write to the event log, be sure to check that.  If you enabled the video recording, you can enable that option too.  We don’t need to choose any of the advanced options.  Once you have selected the diagnostic settings, click finish to create it.

Before we configure our Test Plan with these settings, we need a build to test against.  We will need to create a new build definition, so reopen the test project solution in Visual Studio 2010 if it isn’t still open.  In the Team Explorer window, right click on Builds and choose New Build Definition.  The build definition will be pre-populated with the information from the solution.  Choose a drop folder (you may have to create a share for this if one isn’t already created).  Lastly, we are not going to run these tests from the build.  Refer to my previous post if you want to also configure this.   By default it will try to run the tests.  Go to the Advanced settings and disable the Automated Tests.

Save the build.  Right click on the build and choose Queue new build.

Now that we have the build, test settings, and environment our last step is to assign these to the Test Plan.  Switch back Test Manager and make sure you are in Testing Center.  Choose the Organize tab and Open Test Plan.  First under Automated runs settings, choose the testing settings that you created.  If it isn’t in the list, make sure you selected Automated for the settings.  Next choose the environment.

Next choose the build definition that you created and click Set build filter.

Assign the latest build of the build definition by click on the modify link.  Then choose the appropriate build and click Assign to plan.

The settings for the automated test to run from Microsoft Test Manager are complete.  Let’s go back to the test and run it as an automated test.

Switch back to the Test tab.  Locate the test that you created.  Right click on the test and choose Run.  This will open the Test Run screen.  Notice, now this test is automated it no longer starts the test runner by default.  If you want to run the test manually, choose Run with options to choose to run it manually.

Here you can see the test is running on the Test machine while the test run shows that it is in progress.  The test run does not refresh very well.  Be sure to manually click on the refresh or it may appear to jump to finished.

Here the test shows that has completed and the status is passed. 

 

Lastly, you can look at the test results to view the status and see any of the diagnostic data.   The ScreenCapture.xesc is video recording of the test.  This is usual because normally you wouldn’t be logged into the machine running the test.  Be sure that the machine that is viewing the screen capture also has the Microsoft Encoder installed.

I know this ended up being a long post.  I hope you found it useful.  As always if you have any questions or want to find out more information how Deliveron helps clients with their ALM initiatives, please contact us at tfs@deliveron.com,  http://www.deliveron.com, or the phone number at the top of the screen.

This is also cross posted at http://www.deliveron.com/blog/post/Running-Automated-Tests-from-Microsoft-Test-Manager.aspx

Mike Douglas

Development teams utilizing Coded UI Tests have several options where to run Coded UI Tests.  When a developer creates an automated test either from an existing action recording or using the Coded UI Test Builder, the test can be run within Visual Studio 2010 just like a unit test.  Once the Coded UI test is passing, it can be associated with a Test Case and/or run as part of the build along with the unit tests.  I will cover associating a Coded UI Test to a Test Case and running the automated test within Microsoft Test Manager in a future post.  In this post I will cover configuring the build server to run Coded UI Tests.  While this post describes configuring the build server to run the Coded UI Tests, any machine configured as a test agent can be utilized by the build server and build to run the Coded UI Tests.

The primary difference between running the Coded UI Test on the build server than a unit test is that the test requires full access to the UI.  Having the build server require full access to the UI introduces a couple challenges including a couple additional requirements.  First, the build server requires the application to be installed on the build server the same way it was installed when the test was recorded.  The build server also requires a Visual Studio 2010 Test Agent running on it.  It also needs to be configured to record video if required.  Finally the build has to be configured to run the Coded UI Tests.  The following steps walk through configuring these items.

Configuring the Test Agent to Run Coded UI Tests

1. Run the Microsoft Visual Studio 2010 Test Agent Configuration Tool (Start > Program Files > Visual Studio 2010 > Visual Studio 2010 Test Agent Configuration Tool)

2. Configure the Test Agent to Run Interactive

3. Ensure that Log on automatically and Ensure screen saver is disabled are checked.  This will enable the server to be ready to run the tests even if the server is rebooted.   Also, the screen saver has to be disabled so the machine doesn’t get locked.  The Coded UI Tests can not run if the screen is locked. If you use Remote Desktop (RDP) to connect to the server, when you log out the machine it will automatically lock it.  To prevent this from happening, you must log into it from the machine or VM console.  If this is not an option, an alternative is to log on to another server such as the TFS server, then RDP into the build server from the TFS server and close the RDP session to the TFS server to lock this server but the build server remains unlocked and the Coded UI Tests will be able to run.

4. Register the Test Agent to a Test Controller that is not configured for Test Manager.  Unfortunately, the Coded UI tests run from the Build Server can not share the same test controller. 

Enabling Video Recording for the Automated Tests

One of the options in the test settings is to enabling video recording as part of the data collection.  By default the server doesn’t have the required components and configuration to enable this.  Follow these steps to enable the video recording.

1. Install the RTM Update for Lab Management on the Build Server
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8406ef19-35a3-4c03-a145-08ba982f3cef&displaylang=en

2. Install Microsoft Expression Encoder
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=75402be0-c603-4998-a79c-becdd197aa79

3. If the Build Server is Windows Server then enable the Desktop Experience Feature.

Configuring the Build to run the Coded UI Tests

The final part to configure is to configure the build to run the Coded UI Tests.

1. Open the Test Settings file in Visual Studio by clicking Test > Edit Test Settings > Local.

2. Create a copy by clicking “Save As” and call it something like “BuildServer”. 

3. Change the name to “BuildServer”.

4. Choose the Roles item.  Change the local execution to “Remote Execution”.

5.  Enter the name of the Test Controller that the Test Agent on the build server is using.

If you get the error “The following test controller is not available : YourServer.  You must remove the association using the Lab Center within Microsoft Test Manager”, then you must remove this association.

a. To remove the association, remove the registration in the Visual Studio 2010 Test Controller Configuration Tool.  Uncheck the “Register with Team Project Collection” option.
 

6. The Roles item in the BuildServer Test Settings should look like the following

7. Close the Test Settings and Check in the new build definition file.

8. Open the Build Definition.  Click on the Process tab.  Expand the Automated Tests > Test Assembly.  Click on the TestSettings File ellipse.  Chose the BuildServer  test settings file.

9. Save the build definition and queue the new build.  The Coded UI Test should run on the build and your test should pass. If the test fails, open the test results and view the details the same way you would do for a broken unit test.

This is a cross post from the Deliveron blog. http://www.deliveron.com/blog/post/Configuring-a-TFS-2010-Team-Build-Server-to-Run-Coded-UI-Tests.aspx

One of the most exciting things to me in Visual Studio 2010 ALM is the elimination of silos around development, project management, and quality assurance.  In previous version these roles and activities were isolated and disconnected with little traceability between them. 

In Visual Studio 2010 ALM these silos are removed and there is now traceability across the developer, project management, and quality assurance roles because of the emphasis around testing in Visual Studio 2010. The introduction of Microsoft Test Manager, included with Visual Studio 2010 Ultimate and Visual Studio 2010 Test Professional, to create and manage Test Plans and manually run Test Cases has filled a much needed gap in the ALM space.

To visualize the traceability, we have created the Visual Studio 2010 ALM Traceability Matrix to show the relationships between the major work items/artifacts in Visual Studio 2010 ALM. This could include additional links between these items, but we have not included every possible combination for readability. What I found with this matrix helps people relate this to their own environment and start seeing benefits of having all of this information centralized utilizing Visual Studio 2010 ALM and Team Foundation Server (TFS) 2010.  Below the matrix are some examples of questions that can be answered by TFS related to traceability between these items.  The data warehouse in TFS 2010 can be used to answer many more questions for every level of your organization.

User Stories (1)
How many hours of remaining work are left for this User Story?
Who are the developers working on this User Story?
Is the User Story covered by test cases?
Are the tests passing for the User Story?
Is the User Story done?

Tasks (2)
What bugs have been fixed for a User Story?
Is the task complete so the test case be moved to ready?

Test Plan (3)
What stories are in a Test Plan/Iteration?
How many automated tests are in the the Test Plan?
How many tests are passing in this Iteration/release/test plan from the previous one?
How many bugs were fixed?

Test Suites (4)
What are the group of test cases for the User Story?

Test Cases (5)
Are all of the tests passing for a particular Iteration/Test Plan?
How many iterations has this test been passing?

Automate Tests (6)
How many tests are automated for a User Story or Iteration/Test Plan?
Are there are any regression tests failing?
What is the test coverage for User Stories?

Code/Changesets (7)
What changesets are included in this build? 
What tests are impacted by this check-in?
What is the User Story and Test Plan for this changeset?
Has this changeset been released?

Builds (8)
What test cases are impacted by the code changes in this build?
What build is being used to run the tests against?
What User Stories and/or Test Cases have been tested by this build?

What kind of questions come to mind for your organization around these items?  Send me your thoughts or questions to tfs@deliveron.com

Mike

This is a cross post of http://www.deliveron.com/blog/post/Visual-Studio-2010-ALM-Traceability.aspx

One of my Team Foundation Server 2010 test servers had TFS 2010, VS 2010, and Team Explorer 2010.  Installed the TFS 2010 Power tools to utilize some of the cmdlets and the tfpt.exe utility to create a team project.  After I did this I also needed to test the TFS Administration Tool 2.0 for TFS 2010.  This is a great and free tool for managing the permissions of TFS users across TFS, SSRS, and SharePoint.   This works with TFS 2010 but it is written against the TFS 2008 object model.  This required

• Team Explorer 2008
• Visual Studio 2008 SP1
• Visual Studio 2008 SP1 Forward Compatibility Hotfix

I installed these pre-requisites and the TFS Admin Tool.  Today I got a request to add some additional email alerts to a TFS 2008 team project.   Since I already had Team Explorer 2008, I installed the TFS 2008 Power tools to get the alerts feature (The TFS 2010 Power tools doesn’t have this feature)..

I went back to work on my script for automated team project creation.

I ran my script

tfpt createteamproject /collection:http://dlvrn2010md:8080/tfs/defaultcollection /teamproject:"testauto5" /processtemplate:"MSF for Agile Software Development v5.0" /sourcecontrol:New

Then I get the following error:

TFPT.exe : Unrecognized command option 'collection'.

I realized the TFPT command is now pointing to the TFS 2008 Power tool version and obviously doesn’t know what a Team Project Collection is.  I looked in the Environment Variables.  The Path variable showed a reference to the TFSPowerToolsDir variable.

Next, I checked the TFSPowerToolDir variable and it was pointing to the 2008 Power Tools.

I changed this to "C:\Program Files (x86)\Microsoft Team Foundation Server 2010 Power Tools\".  I reopened the PowerShell ISE, executed the script, and it worked again.

This is a unique situation, but it happened to me so it could happen to you :)

This is also posted at http://www.deliveron.com/blog/post/Fix-TFS-2010-Power-Tools-after-installing-TFS-2008-Power-Tools.aspx

Today I have released Team Deploy 2010 for Team Foundation Server 2010.  In this post, I am going to give a quick overview of Team Deploy if you haven’t used it before, explain this release and upcoming releases, compare it to Lab Management 2010, and give a walkthrough for setting it up and uninstalling it.

What is Team Deploy?

Team Deploy is a set of custom build activities used to deploy MSIs to multiple client PCs and/or deploy services to servers.  This activities include the ability to kill processes, start/stop services, pass in arguments to the MSIs, provide the service username/password, and uninstall previous versions.  Team Deploy uses SysInternal’s PSTools to remotely execute MSIEXEC to install the MSIs and PSKill to kill processes.  By using Team Deploy, development teams can create automated build and deploy processes for better configuration management.  Deployments can be done on demand or scheduled just like any other build in Team Build.  If you are using Team Foundation Server 2008, Team Deploy 2.1 is the current release to download.  Team Deploy is open source and free to use.  It can be downloaded from http://teamdeploy.codeplex.com

This Release and Future Plans

I am calling this version of Team Deploy 2010, Release 1.  This release is a 1 for 1 port of the MSBuild tasks to Workflow custom activities.  I wanted to release this version without any additional enhancements so development teams can upgrade their build definitions to workflow.  I have a lot ideas for future versions.  Lab Management 2010 has given me some ideas (see comparison below) and there are several other things I want to do.  Here is a list of some:

• MSI Package for Team Deploy 2010 – For custom build tasks, deployments are easy.  Basically just copy the Dll to the MSBuilds folder and use that path in the build definitions.  For Team Build custom activities, it is a little more complicated.  As you will see in the Setup Walkthrough below, there are several steps that are fairly easy to do manually but are going to be more difficult to do with a custom task.  I have begun working on this but it wasn’t ready for this release.
• Breakout Deploy activity into Workflow – Currently the Deploy activity does all the work and calls the other activities within code.  I want to create an additional workflow with all of these steps in a workflow.
• PowerShell capabilities – PowerShell 2.0 has the ability to be run on remote machines.  I want to research this functionality and see if it makes sense to create an addition set of activities that use PowerShell instead of PSTools.
• Custom Build Definition Screen – Display screen to create the deployment options through the UI instead of creating it in XML today.
• Change the Threadpool to .Net 4 Tasks for deploying to multiple machines at the same time.
• Team Deploy build definition to call another definition to  do the build and deploy (Similar to Lab Management)

Team Deploy and Lab Management

Visual Studio 2010 introduces an additional product for Team Foundation Server 2010 called Lab Management 2010.  This product allows virtual environments be created, quickly provisioned, used for manual and automated testing.  Lab Management also includes a new build definition type and activities.  With the build definition type, it allows you to revert the virtual environment to a baseline snapshot, build the application, deploy the application, run the automated tests, and capture the results.  So Lab Management can do what Team Deploy can do and a lot more.   The one area that I have seen Team Deploy used where Lab Management would not be used is for deploying applications to QA and Production.  I have worked with several companies that use Team Deploy to deploy to all of their environments for a consistent deployment process.

Team Deploy Setup

Here are the steps to install Team Deploy and create a simple build.

1. The TeamDeploy2010_R1.zip file contains the following 4 files that are used to install the application.

2. Copy TeamDeploy.Activities.* to a location in source control and check in.

3. Add TeamDeploy.Activities.dll to the GAC using Gacutil.

4. Add source control location of custom assemblies to build controller.  ($/TestBuilds/CustomActivities in this example)

5. Copy DeployTemplate.xaml to source control in the BuildProcessTemplates folder.

6. Create a new build definition.  In the Process Step click on “New” Template and add the existing DeployTemplate.xaml template that was added to source control.  Click OK.

7. Set the build properties to where the PSTools is installed and where the deployment XML is located. Click Save.

8. Rename and edit SampleDeployScript.xml to specify applications to install and machines to deploy to.  See http://teamdeploy.codeplex.com website for full list of options available. If you open the DeployTemplate.xaml.  It should look like this. 

 

If there is an error for the deploy activity.  Delete the AgentScope activity.

1.  Add Team Deploy 2010 Activities by right clicking in the toolbox and select “Choose Items…”. Make sure System.Activities Components tab is selected and select “Browse…” to find the location of the TeamDeploy.Activities.dll and choose it.

  2. Once you have added the TeamDeploy.Activities.dll, you will see the activities selected.  Click Ok.

3. Clicking Ok will add the activities to the toolbox. Drag the Deploy activity to the AgentScope container.  The required properties will cause a red error icon to display.  Fill out the properties to where you have the deployment script and PSTools installed. (Sometimes the designer won’t let you drag the Deploy activity to the canvas.  Save the workflow, exit Visual Studio 2010, and reopen the workflow.  It should then.

Uninstalling or Updating Team Deploy 2010

1. Close Visual Studio 2010

2. Stop the Visual Studio Team Foundation Build Service Host service.

3. To remove Team Deploy from the GAC, browse to c:\windows\microsoft.net\assembly\gac_msil and delete the TeamDeploy.Activities folder.

Build Log of Deploy activity in Team Build 2010

Here is an example of the build log for the Deploy activity.

I hope you enjoy!  Let me know if you have any ideas or run into problems.

Mike

Thanks everyone for coming on Tuesday to the Omaha Team System User Group meeting to see my presentation on What’s New for Testing in Visual Studio 2010 and TFS 2010.  It was a great turnout and there were a lot of great dialog and questions asked. 

Here’s the slides from the presentation.
http://www.codesmartnothard.com/content/binary/Whats_New_for_Testing_in_Visual_Studio_2010.zip

If you missed it or know anyone else that wants to see it, I’m doing this presentation again on a Webcast on April 14th at 11:00 (central time).  Here’s the link:
https://www.clicktoattend.com/invitation.aspx?code=146828

Contact us below if you would like more information about implementing Team Foundation Server and/or Visual Studio Lab Management 2010.

Thanks,
Mike