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

I’m excited to be speaking 3 times in the next month on the new testing capabilities in Visual Studio 2010 and TFS 2010.  Two events are listed below.  The third event is full.  I hope you can make one of them.

Sign up for the Deliveron Newsletter to be notified about future presentations.

Presentation Overview

Visual Studio 2010 introduces Lab Management 2010 and Test Professional 2010 to remove the silos between QA professionals and developers to establish a more cohesive development and testing process.  Together these products include tools and features for creating test plans, creating and running manual tests, automated UI testing, creating test virtual environments, recording manual tests, and collecting diagnostic and error data to easily include with bugs.  See how everyone on your development and testing teams can take advantage of these improvements

Omaha Team System User Group Meeting

March 23, 2010 at 6:00pm
Farm Credit Services of America
5015 S 118th St
Omaha, NE 68137
Register here

Deliveron April Webcast

April 14th, 2010 at 11:00am Central Time
Register here

This is Part 4 of my Deployments with TFS series. It has been awhile since I started putting this information together but I haven’t found time to finish this.   A question about building ClickOnce deployments with Team Build 2008 on the MSDN forums was just what I needed to get this posted.

What is ClickOnce?

ClickOnce is a deployment technology that enables you to create self-updating windows based applications that can be installed and run with minimal user interaction.  For a complete overview of ClickOnce, please visit this the ClickOnce Deployment Overview article on MSDN.

Our Requirements

Our requirements contained a couple items that made our deployment more complicated.  The first one is one a configuration management issue that I strongly pushed.  Basically there were two environments, Test and Production.  The ClickOnce was to be built and deployed to the Test server, tested and accepted, and finally pushed to production.  The problem is that Test used different config files than Production.  The thing we didn't want to do is to have to rebuild the application to update the config files, recreate the manifest, and publish to the production.  This had the potential to introduce something different than was tested.Fortunately our Production Release build script was able to copy in the new config files and recreate the manifest and push to production.  The helped ensure the same version of the assemblies tested.  Of course nothing is perfect, we could have still had problems in our config files. :)

The next issue is that we wanted to run Test and Production at the same time to compare if there were problems.  ClickOnce thought these were the same applications so we were unable to run them both.  The solution for this was to use a different key for each environment.  In Test we used a test certificate key that we created, in Production, we used our issued certificate key.  With this, the assemblies could be the same or different versions and ClickOnce treated them as two separate applications.

The Solution

The solution consisted of 4 build scripts

1. Build and Stage to Test – This builds the application, creates the ClickOnce manifest, and then publishes it to a folder share, ready to be deployed to Test (but not yet).
2. Deploy to Test – This script copies the ClickOnce application to the web server so the application is available to the testers.  This script also deployed a WCF Windows service.
3. Stage to Production – This script copied the production config file into the manifest folder, recreated the manifest (with production certificate), and copied the ClickOnce application to a staging folder on a production (so it could be deployed at a later time).
4. Deploy to Production – This script copies the ClickOnce application from the production staging folder to the production web server.

The “staging” builds could be combined with the “deployment” builds but I believe by separating these it offers the most flexibility.  I will now highlight some of the unique things I had to do to get this all to work.  Unfortunately it wasn’t as simple as using the MSBUILD task.  I think this would work for a demo or simple scenario but not a real world scenario.  There wasn’t any way to change any of the settings.  This offers more options.

Build and Stage To Test

The first part is the properties.  Here I set all of the ClickOnce properties that will be used later on in the build.

<PropertyGroup>
  <TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>
  <PublishUrl>\\myserver\deployments\coolapp\current\ClickOnceStage\</PublishUrl>
  <ClickOnceAppName>MyCompany.CoolApp</ClickOnceAppName>
  <ClickOnceExeFile>MyCompany.CoolApp.exe</ClickOnceExeFile>
  <ClickOnceProduct>Cool Application</ClickOnceProduct>
  <Company>My Company</Company>
  <ClickOnceDescription></ClickOnceDescription>
  <ClickOnceUrl>http://testserver.mycompany.com/</ClickOnceUrl>
  <SigningCert>$(SolutionRoot)\MyCompany.CoolApp\CoolApp_1_TemporaryKey.pfx</SigningCert>
  <SigningCertPassword>1234</SigningCertPassword>
</PropertyGroup>

The first trick is to edit project file and update the publish url.   This allows the build to edit it but not check out the file and need to check it in.  Do this before the build by overriding the BeforeCompile target.

<Target Name ="BeforeCompile">
  <Message Text="Making csproj file writable"/>
  <Exec Command="attrib -R &quot;$(SolutionRoot)\MyCompany.CoolApp\MyCompany.CoolApp.csproj&quot;"/>

  <Message Text="Replacing PublishUrl"/>
  <File.RegEx
    Path="$(SolutionRoot)\MyCompany.CoolApp\MyCompany.CoolApp.csproj"
    RegularExpression="&lt;PublishUrl&gt;(.*?)&lt;/PublishUrl&gt;"
    NewValue="&lt;PublishUrl&gt;$(PublishUrl)&lt;/PublishUrl&gt;"
     />
</Target>

Take the publish.htm file from a manual ClickOnce publish change the version to a tag that can be replaced by the updated version number and check it in to the solution.  After the compile, use the modified version of the publish.htm file copy it to the staging location and then replace it with the version.  MaxVersion is the variable the represents the new version.  I like to keep the assembly version the same as the ClickOnce version.

<Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
  <!-- Copy modified publish htm file to staging publish location -->
  <Copy SourceFiles="$(SolutionRoot)\publish.htm" DestinationFolder="$(PublishUrl)" />

  <ItemGroup>
    <WebPage Include="$(PublishUrl)\publish.htm" />
  </ItemGroup>

  <RegEx
    Condition="Exists(@(WebPage))"
    Path="@(WebPage)"
    RegularExpression="#VERSION#"
    NewValue="$(MaxVersion)"
    Force="true"/>
</Target>

Next, I used a couple of custom tasks I created.  The first was to get the framework version.  I couldn’t figure out a way to do this.  Basically this just returns the .net framework path so I can call Mage.exe.  The second one takes the name of the app and the version to create the manifest folder.  Then it does the heavy lifting to create the ClickOnce application.  We have to do each step to make this work.  There is one thing you will probably noticed is that the setup.exe is renamed to CoolAppSetup.exe.  This was done because there was a policy that users couldn’t run setup.exe. I left out the copying of the files to the staging location before running all of this below.  I had to copy the files individually because this build script also built the WCF service.  You will need to add the appropriate process to copy these.

1. Generate the application manifest
2. Sign the application manifest
3. Rename the source files to .deploy
4. Generate the deployment manifest
5. Sign the application manifest (one more time)
6. Create the bootstrapper

<Target Name="AfterEndToEndIteration">
  <GetFrameworkPath>
    <Output TaskParameter="FrameworkPath" PropertyName="FrameworkPath" />
  </GetFrameworkPath>
  <CreateManifestName ExecutableName="MyCompany.CoolApp" ExecutableVersion="$(MaxVersion)">
    <Output TaskParameter="ManifestName" PropertyName="ManifestName" />
  </CreateManifestName>
  <PropertyGroup>
    <ClickOnceApplicationUrl>$(ClickOnceUrl)$(ClickOnceAppName).application</ClickOnceApplicationUrl>
    <PublishDir>$(PublishUrl)</PublishDir>
    <AppPublishDir>$(PublishDir)Application Files\$(ManifestName)</AppPublishDir>
    <SdkPath>$(FrameworkPath)\</SdkPath>
    <VersionNumber>$(MaxVersion)</VersionNumber>
  </PropertyGroup>

  <Message Text="FrameworkPath = $(FrameworkPath)" />
  <BuildStep
    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    BuildUri="$(BuildUri)"
    Message="Building $(ClickOnceAppName) ClickOnce version: $(VersionNumber)">
    <Output TaskParameter="Id" PropertyName="StepId" />
  </BuildStep>

  <!--
************************************************
Generate application manifest
************************************************
-->
  <Exec
  Command="mage.exe -New Application -TrustLevel FullTrust -ToFile &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -Name &quot;$(ClickOnceAppName)&quot; -Version &quot;$(VersionNumber)&quot; -FromDirectory &quot;$(AppPublishDir)"
  WorkingDirectory="$(SdkPath)"/>

  <!--
************************************************
Sign application manifest
************************************************
-->
  <!--<Exec Condition="'$(SigningCertPassword)'==''"
    Command="mage.exe -Sign &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -CertFile &quot;$(SigningCert)&quot;"
    WorkingDirectory="$(SdkPath)"  />-->

  <Exec Condition="'$(SigningCertPassword)'!=''"
      Command="mage.exe -Sign &quot;$(AppPublishDir)\$(ClickOnceExeFile).manifest&quot; -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"
      WorkingDirectory="$(SdkPath)"/>

  <!--
************************************************
Rename source files to .deploy
************************************************
-->
  <ItemGroup>
    <SourceFilesToRename Include="$(AppPublishDir)\**\*.*"
                         Exclude="$(AppPublishDir)\*.manifest;$(AppPublishDir)\*.htm"/>
    <SourceFilesToDelete Include="$(AppPublishDir)\**\*.*"
                         Exclude="$(AppPublishDir)\*.application;$(AppPublishDir)\*.manifest;$(AppPublishDir)\*.htm"/>
  </ItemGroup>

  <Copy
      SourceFiles="@(SourceFilesToRename)"
      DestinationFiles="@(SourceFilesToRename->'$(AppPublishDir)\%(RecursiveDir)%(Filename)%(Extension).deploy')"
      />

  <Delete Files="@(SourceFilesToDelete)"/>

  <!--
************************************************
Generate deployment manifest
************************************************
-->
  <CreateItem Include="$(AppPublishDir)\$(ClickOnceExeFile).manifest" AdditionalMetadata="TargetPath=Application Files\$(ManifestName)\$(ClickOnceExeFile).manifest">
    <Output TaskParameter="Include" ItemName="ApplicationManifest"/>
  </CreateItem>

  <Message Text="@(ApplicationManifest)" />

  <GenerateDeploymentManifest
    MapFileExtensions="true"
    AssemblyName="$(ClickOnceAppName).application"
    AssemblyVersion="$(VersionNumber)"
    Description="$(ClickOnceDescription)"
    Product="$(ClickOnceProduct)"
    Publisher="$(Company)"
    SupportUrl="$(SupportUrl)"
    EntryPoint="@(ApplicationManifest)"
    Install="false"
    UpdateEnabled="true"
    UpdateInterval="7"
    UpdateMode="Foreground"
    OutputManifest="$(PublishDir)\$(ClickOnceAppName).application"/>

  <!--
************************************************
Sign application manifest
************************************************
-->
  <!--<Exec Condition="'$(SigningCertPassword)'==''"
      Command="mage.exe -Sign &quot;$(PublishDir)\$(ClickOnceAppName).application&quot; -CertFile &quot;$(SigningCert)&quot;"
      WorkingDirectory="$(SdkPath)"/>-->
  <Exec Condition="'$(SigningCertPassword)'!=''"
      Command="mage.exe -Sign &quot;$(PublishDir)\$(ClickOnceAppName).application&quot; -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"
      WorkingDirectory="$(SdkPath)"/>

  <!--
************************************************
Generate Bootstrapper
************************************************
-->
  <ItemGroup>
    <BootstrapperFile Include="Microsoft.Net.Framework.3.5">
      <ProductName>Microsoft .NET Framework 3.5</ProductName>
    </BootstrapperFile>
    <BootstrapperFile Include="Microsoft.Windows.Installer.3.1">
      <ProductName>Windows Installer 3.1</ProductName>
    </BootstrapperFile>
  </ItemGroup>

  <GenerateBootstrapper
    ApplicationFile="$(ClickOnceAppName).application"
    ApplicationName="$(ClickOnceAppName)"
    ApplicationUrl="$(ClickOnceUrl)"
    BootstrapperItems="@(BootstrapperFile)"
    Culture="en"
    FallbackCulture="en-US"
    CopyComponents="true"
    Validate="false"
    OutputPath="$(PublishDir)"/>

  <Copy SourceFiles="$(PublishDir)\Setup.exe" DestinationFiles="$(PublishDir)\CoolAppSetup.exe" />
  <Delete Files="$(PublishDir)\Setup.exe" />

  <BuildStep
    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    BuildUri="$(BuildUri)"
    Id="$(StepId)"
    Status="Succeeded"/>

  <OnError ExecuteTargets="MarkBuildStepAsFailed" />
</Target>

<!--
************************************************
Mark the buildstep as failed
************************************************
-->
<Target Name="MarkBuildStepAsFailed">
  <BuildStep
    TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    BuildUri="$(BuildUri)"
    Id="$(StepId)"
    Status="Failed"/>
</Target>

The Deploy Builds are simply a Copy task to copy the files to the web server.  Do this by creating a share to the same location so you can use a UNC.  The production stage build is basically all of the above again but with the production certificate key and copy the new config file(s) to the production stage location.

Looking back on this it seems complex but this is what the publish wizard is doing behind the scenes and offers complete customizing to fit your needs.  I sliced, diced, and renamed items in the scripts above.  I tried to make sure everything is correct.  If there is a typo or something missing, please let me know and will update it.

Enjoy!

Mike

In previous versions of Team Foundation Server there was not a way to install and configure TFS to be run in a completely high available environment.  TFS 2008 supports the data tier running in a SQL Server Cluster.  If the TFS application tier server crashed, there could be a “warm standby” configured to take over but required a manual process to do this.   TFS 2010 supports running multiple Application tier servers using Network Load Balancing (NLB).  Last year I first heard of topology improvements in TFS 2010 in Brian Harry’s post about the Administrator, Operations,and Setup Improvements in Team Foundation Server 2010.  I think this is an extremely important feature as companies are utilizing more features in Team Foundation Server and expecting these services to always be available.

In this post I am going to explain:

• Configuring the second TFS application tier
• Enabling and configuring Network Load Balancing in Windows Server 2008 R2
• Testing TFS using the NLB Application tier severs
• Lessons learned

 

Team Foundation Server 2010 Farm Network Topology Diagram

This is a diagram shows the topology of the TFS configuration I created to demonstrate the NLB option.

 

 

I set up this environment on a laptop.  I installed Windows Server 2008 R2 x64 on the laptop as the host OS to utilize Hyper-V.   I added Active Directory Domain Services (ADDS) and DNS to this machine and configured it as the domain controller.  I installed SQL Server 2008 R2 x64 on it also to be the data tier for the TFS installation.  Both TFS Application Tier Servers were created as Hyper-V virtual machines with Windows 2008 R2 x64.  To make this configuration 100% redundant I would have needed to install the reporting services on both of the TFS Servers, used a SharePoint 2007 Farm for the portal, and a SQL Server cluster for the data tier.  In fact, now that I have all of this working, I am going to uninstall everything and try to get WSS and SSRS installed on both application tiers also utilizing the NLB.  This would allow for 100% redundant and high availability for all of the TFS 2010 Components with only 4 servers (creating a 2 server SQL Server Cluster). I will post a follow up on how this goes..

 

Team Foundation Server Installation

The TFS installation and configuration for the first server (TFS2010A) was done just as if it was going to be the only server.  Here are the settings after I installed the first server.

 

For the second server (TFS2010B), the only pre-requisites that were required were IIS 7 and SQL Client connectivity tools.    Below are the steps for configuring the second TFS Server.

In the TFS configuration, choose the “Application-Tier Only” installation option.

The first step was the Welcome step.  There were no options on this step.  The next step is to specify the configuration database that was created when the first server was configured. 

Next, specify the service account for the the new application tier.  I chose to use the same domain account that I used for the first server.

 

This screen shows the summary of the settings that were chosen before the verification is run.

 

After the first time I ran the verification I received two errors.  One was that .Net 3.5sp1 wasn’t installed.  I’m not sure why I reported this error.  When I checked it, it was installed.  It could be related to other error.  The other error, TF255040, was that I didn’t have Reporting Services or SQL Server Connectivity tools installed.

 

I installed the connectivity tools and reran the verification process and it passed this time.

 

The configuration completed successfully.

 

The TFS administrative console now shows both application tier servers.

 

 

Setting up Network Load Balancing in Windows 2008 R2 and Hyper-V

Now that both servers are installed and configured correctly, the next step is to set up Network Load Balancing (NLB).  This will allows users to connect to TFS through a single endpoint and allow NLB to balance the traffic and route all of the traffic to one server if the other is unavailable.  This provides high availability in the event of an outage or when the servers need to be updated.

The first thing to do before setting up NLB is to pick a static IP address and create a DNS (A) Record for the shared name.  In this example, TFS2010 is the endpoint that clients such as Visual Studio 2010.  Here is a snapshot of the A records.

 

Here is an article I used to help enable and configure NLB in Windows Server 2008 R2.  Below are the steps I performed to configure it.
http://technet.microsoft.com/en-us/library/cc731695.aspx

For each TFS Application Tier server, install Network Load Balancing by going to Server Manager > Features > Add Features > Network Load Balancing

Once NLB is installed on all of the App Tiers, run the Network Load Balancing Manager by typing nlbmgr at the command prompt.  Then connect to one of the hosts.  I chose TFS2010a first.  Right click on the Network Load Balance node and choose “Add New Cluster”.  Add the current server to the node by walking through the wizard.  You should be able to leave the defaults unless you want to limit the NLB to just port 8080. The last step of the wizard is to assign the Cluster a shared IP Address.  This IP Address is how all of the clients will access and see it.  Make sure this is different than the IP addresses of the any of the nodes in the cluster.

 

Next, add the other host to the cluster by right clicking on the cluster and choosing “Add Host to Cluster”.  Enter the name of the Host to be added to the cluster.

Here is what the Cluster looks like when it is configured.

 

Connect to TFS from Visual Studio 2010

 

Testing the high availability servers

To test the high availability configuration, I am going to take down one of the TFS application tier servers and then both.  First I created the team project while both servers were available.

Then I created a C# windows project, checked it in, and then checked out one of the files.

Next, I disabled the NIC on TFS2010a.

I did a Undo checkout on the file

NLB rerouted the traffic to TFS2010B and it worked perfect.

Next, I Disabled the NIC on TFS2010b so now both are disabled and it should error.

Tried to check out a file and got a TFS not available error as expected.

 

Last, I re-enabled the NIC on TFS2010A

I performed the check out again and worked perfect.

The NLB worked as expected.

 

Lessons Learned

I’m a developer.  I started my IT career as a server and desktop administrator but that was a long time ago.  So setting up a domain to test this scenario was fun but I ran into a few unexpected problems.   Here are a couple things that slowed me down.

• Installed DHCP and DNS with dynamic IP.  Make sure you assign a static IP address to the virtual internal network card on the DC.  Actually now that I have assigned static IP addresses to both of the TFS Servers, DHCP doesn’t even need to be installed.
• I couldn’t reach SQL Server 2008 R2 from the TFS Servers.  I got an TF255049 error in the TFS configuration.  I installed the SQL Server Management Studio and couldn’t connect using that.  I set up aliases and toggled named pipes on and off.  Still couldn’t connect.  Finally I stumbled upon the network protocol configuration for SQL.  TCP and Named Pipes were disabled.   Seems very strange but probably a security precaution.  I enabled TCP/IP and it worked perfect.

 

NLB Issue

I ran into an issue trying to configure NLB on Windows Server 2008 R2 using Hyper-V

“The interface is misconfigured”

Cluster IP address (IP) not added to TCPIP properties

Dedicated IP address (IP) not added to TCPIP properties

Fix is to enable MAC spoofing in the settings of each VM in Hyper-V.

Enjoy!

Mike

We have a lot of exciting things going on at Deliveron Consulting Services. I wanted to post a few of the updates.

Get Social with Deliveron

  Become a Facebook fan of Deliveron: http://www.facebook.com/pages/Deliveron-Consulting-Services/92712059791

  Follow Deliveron on Twitter: http://www.twitter.com/deliveron

   Join the LinkedIn Deliveron Consulting Services Network group.

 

Deliveron Website Updates

We have implemented a few website updates.  These include:

• Deliveron Jumpstart Solutions including the TFS Jumpstart information and flyer. (I am very excited about this!!)
• “The Deliveron Story”
• Areas of Expertise
• Our Partners and Memberships

View the first edition of the Deliveron Monthly Newsletter.  Sign up on the website to receive future newsletters and announcements.

 

Upcoming Events

2/3 – Omaha SQL/BI User Group - Solution Consultant Moe Elatta from Deliveron will be presenting on SQL Server Reporting Services 2008 scale-out configuration and new charting enhancements. Register here...

2/18 - MSDN Webinar - Enhancing the Business Process Automation Capabilities of SharePoint Register here...

2/25 - Lunch and Learn - SharePoint Features You Need Register here...

To me there has always been a feeling a of excitement to be able to build an application and then deliver it to someone that wants it.  When I first started programming over 20 years ago with GW-BASIC on my Tandy 1000 EX, it was limiting that what I built could only be run within GW-BASIC since it was an interpreted language environment and not compiled.  When I bought Quick Basic 4.5, I could finally compile my applications into an EXE and run them outside of the interpreter.  Then I felt like I hit the big time when I was able to build my first setup package in Visual Basic 4.  I remember I built a Hello World caliber application and created a setup package that took 3 or 4 floppy disks.  I didn’t think it could get any better than this :)  Over the years the the excitement about delivering applications became more from the what was built and not how it would be delivered.  Visual Studio has always included functional, no frills setup projects.  3rd Party vendors have created easier to use and more power tools for creating deployment projects such as InstallShield.   Developers who didn’t purchase a 3rd Party tool were limited to using the OOB (out of the box) setup projects within Visual Studio.  While this is functional, the developer has to know where and how to do things and the usability is not very intuitive.  It requires many steps to creating a MSI that I have blogged about in Deployments with TFS Part 2: How to create an automated deployment MSI.   In Visual Studio 2010 there is finally an easy to solution without purchasing an additional production.

Last week I saw this post from Somasegar on Building setup and deployment packages in VS 2010.   Microsoft has partnered with Flexera, makers of InstallShield to create InstallShield Limited Edition for Visual Studio 2010.  This brings the InstallShield graphical interface to Visual Studio.  In addition to providing a highly intuitive interface for building setup packages, this product allows setup packages to be built from with TFS Team Builds.  This has been a major pain point for automated deployments and SCM (Software Configuration Management) processes.  I downloaded and installed InstallShield 2010 LE and here is a walkthrough of the tool.

Download and Installation

Read Somasegar’s blog post on how to download and install it.  (see link above)

 

InstallShield 2010 LE Setup project

Once it is installed and you create a InstallShield Setup project, the Project Assignment view is the default view.  As you can see, the graphic is a guide that explains the parts of the MSI and the steps to create the package.  At the bottom of the screen are the steps to the installation project.  In addition to the steps at the bottom of the guide, there are also intuitive steps to the right that keep all of the package settings cleanly organized.  

This first step is to fill out the basic information about the application that is going to be deployed.

In the second step, required operating systems and prerequisite applications can be specified and enforced when installing the application.  Custom prerequisites can be defined by choosing “Create a custom software condition” under “More Options”.

The installation Architecture section step is disabled in the Limited Edition.  In the other editions different features can be defined for users to choose what sections they want installed.

The next step is the Application Files.  Here the application’s files can be added to the installation.   The “Add Project Outputs” is the primary button for adding the application files.  I found this dialog window to be a lot easier to use than the Visual Studio setup project.

The Application Shortcuts step is where desktop and start menu shortcuts can be defined.

If the application requires any registry entries, they can be defined in the Application Registry step.

The last step is the Installation Interview.  This step asks a series of questions that drive what dialogs the user running the installation will see.  Custom dialogs are not supported in the InstallShield Limited Edition.   Custom dialogs are supported in the Visual Studio setup projects.  For the automated deployment MSIs, I create a dialog that allows the user to specify the environment.

Custom Actions are non-standard activities that can be performed at different points of the installation process.  The Limited Edition supports VBScript, JScript, and Exe custom actions.  However, as shown in the following image, there are only a couple points in the process where custom actions can be defined.  The Premier and Professional editions also support InstallScript, a powerful scripting tool to create more advanced customizations to the installation process.

After I built the MSI, I ran package to install it.  Users will see this message box that the installation was created with a beta version of InstallShield. 

 

InstallShield 2010 LE for Visual Studio 2008

The InstallShield 2010 LE Installation also installs a version that works within Visual Studio 2008.  This interface looks the same in Visual Studio 2008 as it does in Visual Studio 2010.

 

Building MSIs with Team Build 2010

This is the feature I am most looking forward to in InstallShield 2010 LE.  Standard Visual Studio 2008 setup projects can not be built within Team Build without some tricks.  Unfortunately TFS Source Control and Team Build integration is not available in this beta version.  I verified this with Flexera.  They are currently working on it.  As soon as an updated version is available with this enabled I will do a follow up post detailing the TFS Source Control and Team Build experience.  I’m interested to see the following in action:

• Triggering a build and having the MSI compile with the updated assemblies.
• Curious to see if the InstallShield Setup project build can detect new dependencies added.  My tests will include adding a reference to the primary output application.  Then do a new build to see if the MSI will automatically include it.  It might be expecting too much but this would be very beneficial.

 

Overall

• The Project Assistant is a very simple to use series of steps to create a complete setup project.  As users feel more comfortable with the too, they will probably jump to the specific screens they are looking for in the navigation pane on the right.  Both are highly intuitive and significant improvements over the the standard Visual Studio setup projects.
• Most things that are supported in the standard Visual Studio setup project can be accomplished with InstallShield 2010 Limited Edition.  For most installation packages, these limitations will not be problem.  However, I will not be able to create automated deployment MSIs because of the limitations of no custom dialogs and not being able to create custom properties.
• Being able to rebuild the MSIs during each Team Build is a huge benefit.  Once this feature is available, I think it will become my favorite feature.
• I believe Microsoft and Flexera will both win with this product.  Microsoft’s Visual Studio 2010 will include an improved tool for creating installation packages without having to reinvent the wheel.  Flexera has built an amazing and easy to use product that will work for the majority of scenarios, but many will want to upgrade to the Express, Professional, or Premier editions to get the full power of InstallShield.
• The final product should be great, but this beta version is not ready to be used for more than evaluation purposes.  Between the beta message box that is displayed when the user installs it and the fact that the TFS Source Control and Team Build integration features are not available yet, I recommend waiting until the final version is released.

Mike

There is a lot of information about the major updates of TFS 2010 and Team Build 2010 including changing from MSBuild to Workflow and Gated Check-Ins to name a couple.  In using TFS and Team Build 2010 beta 2, there are a lot little features and improvements that help make these two products complete and polished.  Here are a few of the features and I keep discovering new ones each time I use it.

 

New Build Definition will default name and solution to build

if you have a solution open in Visual Studio 2010 when you create a new build definition, the build name will default to the solution name.

 

An open solution will also automatically be populated as the Project to Build

 

The build retention policy is not set to “Keep All” by default.

Finally, the default retention policy for the builds is not set to “Keep All” anymore.  Primarily all results will default to keep the last 10 builds.  In Visual Studio 2008, I always recommended that this should be changed.

 

TFS Build notifies you about successful and failed builds

The Team Foundation Build Notification tool used to be part of the power tools.  Now it is included with the standard installation and alerts you to the success or failure of the build.   This supports continuous integration and gated check-in builds.  The notification dialog window also has an option for unshelving failed gated check-ins.

This dialog displays for a successful Gated Check-in build

 

This dialog is display when a Gated Check-In fails.  Notice the Unshelve Changes option to retrieve the changeset that was be attempted to be checked-in.

Build Parameters are now strongly typed and visible

In Team Build 2008, parameters could be passed in to a build when it was being queued.   However the format was command line argument style passed into a textbox similar to this:

/p:IsThisCool=”false”

In Team Build 2010, the build parameters are displayed as strongly typed properties.   This will allow for type checking and eliminate the misspelling of parameters.

 

Enjoy all of the great new features in Team Build 2010 including these smaller but helpful features!

Mike