Overview

The ALM Rangers heavily leverage the power of Team Foundation Service (TFService) for all of our projects.  While TFSService doesn’t contain all of the features found in on-premises Team Foundation Server, for most projects and applications that we build, the features available within TFService are sufficient.  For this project we are working on the V2 of the ALM Readiness Treasure Map, a Windows 8 Store App.  If you are not familiar with V1, read the article, A Treasure Hunt Through ALM Readiness, in the MSDN magazine and download the app from the Windows 8 Store.  With this project, there are two features that we can’t accomplish with TFSService.  TFService does not include symbol server support.  In addition Windows 8 Store apps cannot be built with Team Foundation Service.  If we were to use an on-premises build server with Team Foundation Service, we could support building the application.  Read the Building and Validating Windows Store Apps with Team Foundation Service article in the April 2013 edition of MSDN Magazine for a great walkthrough on creating an on-premises build server for TFService to build Windows 8 Store apps.

Since we are using a pure TFService solution, we will need to store the symbols, binaries, and the app package in source control for released and internal builds. Below is the solution enabling and using the debug symbols and also storing binaries and packages for release and internal builds.  This is our initial plan and it may evolve as the project progresses.  In addition, hopefully in the future TFService will support both of these features. Be heard and vote for Windows 8 Build Support and Symbol Support on Visual Studio User Voice. As always, we always appreciate your feedback and your ideas for this solution.

Enabling and Using Debug Symbols

Enable full debug symbol information for the release build configuration in addition to the debug build configuration.  This will allow us to have detailed stack information about the error that include line numbers of the errors and debug the application without the source control.

Also ensure that the include public symbols, if any, to enable crash analysis for the app option is checked when creating the app package.

To be able to use the debug symbols within the application, perform the following steps.  The TreasureMap application’s namespace begins with Microsoft, so you need to remove the Microsoft.* exclusion from the options.

Once the symbols have been included, if you wish to debug the issue from production, use Visual Studio to debug the application by choosing Debug Installed App Package… option.

Choose the installed app package to debug

From within Visual Studio, you will be able to hit exceptions and step through the application’s code.

Storing Release Builds

When a release candidate version has been accepted by the Windows app store, take the output from the packaging and binaries and put it into the following folder structure.  Then check-in all of the files into source control as shown below:

Rel\[version]\Binaries

Rel\[version]\PackagedOutput

 

Storing Internal Builds

Internal Only releases should be built locally and stored in the Drop folder in TFService.  Use the following folder structure and naming convention.  Under varTreasureMap_Dev, create a new folder using the format [Date].[Build Number]. In this folder, copy and check in the binaries / output from the build into the Binaries folder.  Also create the app package files locally by choosing Project > Store > Create App Packages.  Be sure to choose No when asked if you want to publish to the Windows Store.  After going through the wizard, copy the output to the PackagedOutput folder under the build folder and check in these files.  Send an email to the team letting them know a new internal version is available for side loading to test.

Continuous Delivery is the process of automatically building, testing, and deploying the application through test and into production at regular intervals.  Windows Azure is Microsoft’s cloud based application hosting platform that provides Infrastructure and Platform as a service solutions for for building, deploying, and managing solutions that can scale to support millions of uses with only configuration changes.  In addition Window Azure can extend your or replace your network infrastructure.  Microsoft also offers a full featured Application Lifecycle Management tool in Azure called Team Foundation Service. 

Setting up Continuous Delivery with Windows Azure and Team Foundation Service is as easy as creating the accounts, linking the two systems together, and checking in your code.  The following post provides a step by step walkthrough of setting up the process.  I have also created build and deploy process for Azure Cloud Service applications for on-premises Team Foundation Servers.  Unlike the out of the box (OOB) solution for Team Foundation Service, setting up the solution for on-premises TFS requires customization and installing additional components.  I will write on this in a future post.

Are you on Team Foundation Service?

The first thing to do is sign up on TFService if you haven’t already do it.  Pricing hasn’t been announced yet but it has been announced that there will be a free tier and a tier included with MSDN.  In addition, right now, while it is still in preview it is free. So, there isn’t any reason to keep from trying it.  Sign up at http://tfs.visualstudio.com.

Sign up for Windows Azure

Signing up for Windows Azure is easy.  You can start using a lot of features for free by signing up through your MSDN account or for a free trial. 

Continuous Delivery Setup

Now that you have both of your accounts, let’s create the Cloud Service to host your application.  When you open the Windows Azure management screen, you will see a list of all available features including the cloud services as shown in figure 1. 

To create the cloud service, choose the Create (+) option in the bottom left corner, the new dialog window will display.  If you are currently in the cloud services area, the following options will automatically populate otherwise choose these options and enter the URL for your site and the preferred region.  It will validate that this name is available with a green checkmark.

Figure 2 – New Cloud Service dialog in Windows Azure

 

Once it has been created, the dashboard will display with the following steps.  Here you can create the deployment settings for your build.  In our instance, we will create our TFS connection and let it create a default staging deployment.  If you want more control over the deployment you will want to create the deployment settings first.  Choose Set up TFS publishing to begin the authorization process to link the two systems.

The Authorize TFS connection dialog will appear where you enter your Team Foundation Service account/collection name.  Select Authorize Now to connect to your TFService account.

It will prompt you with the request to grant Windows Azure access to your TFService account.  Choose Accept.

Next, choose the Team Project that will contain your Cloud Service application.

Once the linking process has completed, it will guide you through the next steps.  If you haven’t already downloaded the Azure SDK tools, you should do this.  If you are unsure if you have these tools installed, when you try to create the solution with Visual Studio in the following step, it will prompt you to download the tools.  Click On Open Visual Studio 2012 to open the IDE with the Team Project opened that you selected above.  Note: This does not open Visual Studio 2012 automatically with elevated permissions.  If you wish to run your solution locally with the cloud emulator, you must run Visual Studio under elevated permissions.

Within Visual Studio 2012, choose New > Project to open the following New Project dialog.  Select the Cloud template folder under the your favorite language folder (C#).  Note: Be sure to create the solution in a folder that is part of your local workspace for the Team Project that was selected.  This will help ensure the easiest process for checking in your files.

The New Windows Azure Cloud Service dialog appears where you can select the different types of cloud service projects.  In this example, I chose ASP.NET MVC 4 Web Role because my system is going to have a front end website for capturing orders.  I also added a Worker Role for order processing that will be used to process the orders is a background process.

The New ASP.NET MVC 4 Project dialog will prompt you to select the appropriate project template.  Note:  Now included are the Single Page Application (SPA) and Face Application project templates that were added with Update 2.

Once the solution has been created, I made a simple change to update the name of the home page title and checked in the entire solution.  Before I checked in, I noticed that the linking process automatically created the CI build definition but the selected project was blank other than the deployment settings and the build was disabled.  There must be a process that waiting for the first check in to identity the appropriate solution to be used in the build definition.  Once I checked in, the build was enabled and started.  It also has the appropriate project selected.  After a few minutes the build completed and my application was deployed.

Using the URL above, I can view my website. 

When I go back into view the Cloud Service in Windows Azure.  You can see that it shows my deployment from TFS and notice that it deployed to the staging environment as the default deployment setting.

Also, notice that both the web role and the worker role projects have been deployed and they are running.  I can verify everything is working in staging.  To promote this to the production instance, you can choose the Swap option highlighted below.  This performs a swap of the production and staging virtual IP addresses.  This allows for minimal downtime and a simple way to rollback by performing the swap a second time.

Summary

As you can see there is strong integration between Windows Azure Cloud Services and Team Foundation Service that is simple to implement.  This integration provides a great out of the box (OOB) solution for Continuous Integration and Delivery.  Try it out today.

You have started writing your first Windows 8 Store app and now you are asking yourself, "Can I set up Continuous Integration (CI) for Windows 8 Store apps like I have done for other projects?"  The answer is yes. By configuring CI for your Windows 8 Store apps, your apps can take advantage of immediate notification at compilation and unit test failures at each check in.  There are a couple things that make Windows 8 Store app development unique that require a few steps to configure.  I will walk through those unique items, show you how to configure the build machine, and show you the results of a successful build.

The TFS Build Agent typically performs the majority of the work during a Team Foundation Build process.  Windows 8 Store apps require that the build agent be installed on a Windows 8 client or Windows Server 2012 machine. This also means that Windows 8 Store apps will not be able to be built using the Team Foundation Service Hosted Build Service.  If you are using TF Service, one option is to use these instructions to configure a local Build Server and use it with the TF Service.

Unit Testing

Windows 8 Store apps include a separate project template for testing Windows 8 applications and class libraries.  This project is designed to only allow valid Windows 8 assemblies and references.  Additionally the unit test project can help validate the appropriate application capabilities are set by having a package manifest for the unit test project.   Visual Studio 2012 Update 2 includes two improvements for unit testing in Windows 8 Store apps:

• [UITestMethod] – Decorate your test methods with this attribute to run on the UI Thread without having to write your own Dispatcher plumbing.
• Assert.ThrowException<T> method provides a more fluent way of writing unit tests that are expecting exceptions to be thrown.

More information on these features in Update 2.

Configuration

The following list contains the primary requirements for configuring a build machine to build and run unit tests for Windows 8 Store apps.

• Build Agent should be tagged with “Win8” or “Win8StoreApp”.
• Visual Studio 2012 must be installed on build server (Premium or Ultimate for Code Coverage).
• Build Agent must be configured to run interactively.
• Windows 8 Developer License must be installed.
• The Security Certificate for the Unit Test project must be installed.

Install and Configure Build Agent

First, install and configure the TFS Build Service on your selected Windows 8 or Windows Server 2012 build machine.  Use the following article, Install Team Foundation Build Service to install and configure the Build Service. Once the Build Service is configured, open the build agent properties from the Team Foundation Server Admin Console and add a new Win8 tag to ensure that the application is built by the appropriate build agent if you have multiple agents configured.

 

Install Visual Studio 2012

In order for Windows 8 Store apps to build, Visual Studio 2012 must be installed.  If you want to capture code coverage results, install the Premium or Ultimate editions otherwise you can install the same edition you are using to develop.

At this point, your Windows 8 Store apps will successfully build on the server.  We will perform the remaining steps to configure the build machine for testing.

Run Build Service Interactively

The Windows Store app unit tests must be able to interact with the desktop. This requires the build service to be configured to run interactively or else you will get the following error:

To configure the Build Agent to run interactively, log into the machine as the user you want the build to run under.  This can’t be Network Service.  The build service user must also:

• Have administrative permissions on the build machine
• Be a member of the Team Foundation Server build service account group
• Have Change and Read permission to the drop folder identified in any build

Open the Team Foundation Server Administration Console.  Under Build Configuration, stop the build service and then open the Properties dialog.  Ensure the service is running under the appropriate user and check the Run the Service Interactively checkbox.  Click the Start button and this will open a command dialog and specify the Build Agent is running in interactive mode.

Install Developer License

If you tried to run a Windows 8 Store app build with unit tests, it would generate the following error that there is no valid developer license found.

There are several methods for installing and managing Developer licenses see Get a developer license (Windows Store apps) for a comprehensive list.  Here we will acquire it through PowerShell because I am currently logged in as the build agent user without a workspace configured to open the solution.

Run the Show-WindowsDeveloperLicenseRegistration cmdlet in PowerShell with elevated permissions. This opens the dialog below. 

Agree to the license and it will prompt you for you Microsoft Account credentials to acquire the developer license.  Once this has been installed, you will have a developer license for the next 30 days.

Now, if you were to try to run a build now, you would get a certificate error from the unit test project.

Install Unit Test Certificate

As the message above shows we next need to install the Unit Test project’s certificate on the machine so it will be trusted.  You can install the .PFX file that is located within the Visual Studio project, but it is recommended that you install .CER certificate file.  There are several ways to generate a .CER file. In this example, we will create the .CER file by creating the Unit Test project’s App Package.  From your development machine, open the solution and right click on the Unit Test project (not the Windows Store app project) and select Store > Create App Packages.

The Create Your Packages wizard will open and ask you if you want to upload to the Windows Store.  Choose no because we just want to create a local package to get the .CER file.  Next keep the defaults but verify at least one architecture is selected.  Click the Create button to initiate the building of the Unit Test project’s app package.  Once it has completed, the dialog will include the link to the files. Click on this and open the appropriate version’s folder.  Within the folder, there are several files including the Security Certificate file (.CER). 

Copy this file to the build machine.  From the build machine open a command prompt window with elevated permissions.  Run the following command to install the certificate to the local store.

Certutil –addstore root your_unit_test_project.cer

When this has completed, it will display that the command has successfully completed.  This completes everything you need to configure a Team Foundation Build Machine capable of compiling and running unit tests for Windows 8 Store apps.

Creating the Build Definition

Now that all of the requirements for building Windows 8 Store apps has been met, let’s create a CI build definition to verify everything has been correctly configured.  In general, the build definition is similar to other CI build definition.  There are a couple differences highlighted below.

Create the build definition by choosing New Build Definition by selecting the option in the Builds tab of Team Explorer.  Under the Trigger tab, choose Continuous Integration for the build to run after each check-in.  Next, in the Workspace tab, ensure the appropriate node is selected.  This is typically mapped at the Team Project or branch level.  In the Build Defaults tab, enter a network share where the output can be copied at the end of the build definition.

Within the Process tab, you will select the Windows 8 Store apps to build (if the solution was open when you created the build definition it will automatically populate as the solution to build.  Next you need to change the Automated Tests search path to be **\*test*.appx to match the special extension of the Windows 8 Store app unit test project.  Also, you will need specify the name of the tag you used when configuring the Build Agent.  In my instance, I used Win8.

Save the build definition.  To manually trigger the build, right click on the definition and select Queue New Build.  Keep the defaults and click Queue to start the build.  If your Windows 8 Store app includes a unit test project it will automatically execute the unit tests and report the results back to the build summary.  After the build completes, the build summary should look similar to this.

Whether you are building Line of Business (LOB) Windows 8 Store apps or working on the next million dollar app idea, you can now utilize the benefits of Continuous Integration with Team Foundation Server and Team Foundation Build.

The 3rd Annual Nebraska Code Camp was another huge success.  The conference again had top notch speakers from around the country including the keynote speaker, Ted Neward.  Deliveron Consulting Services had the honor of being a sponsor for the second year in a row.  Thanks to everyone that stopped by our booth and came to my talk.  It was great seeing familiar faces and meeting a lot of new people.  I’m looking forward to going back again next year.

My talk was Developing a Windows 8 C#/XAML MVVM Application.  I had a lot of fun giving this talk.  I have been learning how to build a Windows 8 Store app for the past 3 months building an application that using TFS 2012 and Windows Azure Mobile Services.  I am hoping to publish to the app store in the next week.  I enjoyed sharing what I have learned so far and explain what is next.  I have the slides and sample code from my talk shared on my SkyDrive.  Feel free to contact me with any questions.  My contact information is in the slide deck.

I recently had a team ask me about changing the default check in option from Resolve to Associate in Team Foundation Server 2012 (TFS 2012). I did some research and found there is a lot of confusion around the available options.  I am going to describe the two main options to help you decide which option will work best for you and your team.  So, why is changing this important? Our Deliveron ALM Delivery Guidance recommends that each person should update his/her tasks before stand-up each day.  We also recommend the hours be zeroed out for completed tasks, however the task should be left open until stand-up.  During the stand-up the task will be moved from Active to Closed where the team can celebrate the victory.  I have seen teams use clapping, snaps, and noise makers to name a few.   When developers check-in his/her code, they should always associate the check-in to the appropriate work item(s) but not choose Resolve.  Resolve is the default option but by choosing this, it will automatically close the Task bypassing being able to close it during the stand-up. 

Figure 1 – Resolve is the default option for Tasks and Bugs

Changing the option to Associate each time seems small but it would be nice to change the default option from Resolve to Associate.  In TFS 2010 it was relatively simple to change this by updating a registry key.  However, in TFS 2012 there are two options that address this in different ways.  Both options have some drawbacks. I will explain the two options and let you make the decision which you prefer.

Removing the Check-In Action from the Work Item Template (WIT)

One way to address this is to remove the Check-In action from each WIT.  Using the TFS Power Tools, you can remove the Action from the Transition.  In the Task, you need to remove it from the New –> Closed and the Active –> Closed transitions.  To do this, double click on the Transition title bar to open the Workflow Transition dialog.  Navigate to the Actions tab and delete the Action.  In addition to the Task, you should also remove this from the Bug WIT since these are the two types of work items that you would typically associate your check-ins to.

Figure 2 – Removing the Check-In action from the WIT

Once the WITs have been updated into your team project this will be available for all users.  Now when you add a related work item, the only option available is Associate.

Figure 3 – The default and only option is Associate

As I mentioned, this solution has some pros and cons. Here is a few to consider:

Pros

• This change only has to be made the Team Project and nothing has to be done on the clients.
• We recommend not resolving the work item, so removing this option is not a big deal.

Cons

• This would need to be applied to all current Team Projects and would need to update the Process Template for future Team Projects.
• This removes the Resolve option for users, so there is no way to perform this action anymore.

 

Updating Visual Studio clients to change the default option to Associate

This option sounds good.  Unfortunately it only works under one scenario.  With the Team Explorer 2012, there are two primary ways to initiate a check in.  You can initiate the check in from the Pending Changes Pane and from My Work Pane.  By default if you initiate the check-in from either location, the default option will be Resolve.  Once this fix has been applied, it will update the default option when initiating the action from the My Work pane but not the Pending Changes Pane.  I will show you how to set this up but first I will show you the scenario that doesn’t work and the one that does work.

From my experience, most check-ins are initiated from the Pending Changes pane or by right clicking on a location in Solution explorer.  Either way you will end up on the Pending Changes pane, where you can associate a work item by query or by ID.  Unfortunately the change has no effect on this and will continue to default to the Resolve option as shown below.

Figure 4 – Pending Changes still defaults to Resolve after updating the registry key.

In Team Explorer 2012, there is a new Pane called My Work.  This Pane is designed to group and manage all of your current work including code, break points, and associated work items.  This provides the ability to suspend/resume your current work so you can switch to work on something else and then come back to it later with everything the way you left it.  After applying the update, initiating the check-in from here will change the default option to Associate.

Figure 5 – Initiating the check in from My Work changes the default to Associate after the updating the registry key.

Now that you understand the scenarios.  To enable this option, each Visual Studio user will need to update the following registry key and change ResolveAsDefaultCheckinAction = False.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior

 

 
Figure 6 – Set ResolveAsDefaultCheckinAction = False

Next, exit all instances of Visual Studio 2012.  Open the Developer Command Prompt for VS 2012 with administrator privileges.  Run devenv /setup to ensure that the registry is picked up by Visual Studio.

Figure 7 – Run devenv /setup to ensure registry change is applied.

With the change applied, the default option is changed for your My Work initiated check ins.

For this option, here are several pros and cons:

Pros

• This change only has to be made once for it to apply to all TFS servers and Team Projects that you use.
• This keeps the Resolve option for the most flexibility.
• Only developers that want to change the default option will be affected.

Cons

• Most check ins are initiated from the solution or Pending Changes where this update does not work.
• Each Visual Studio user needs to perform this update for it to work for them.

Summary

As you can see there isn’t a perfect option.  Hopefully this gives you a complete picture of the options so you can make the best decision for your team. We chose the first option because the Resolve option would be rarely used.

Mike

Recently, I have had two article published on MSDN and had the opportunity to help do a technical review for a book.  Here are the overviews and links to the full articles in case you missed them.

Testing for Continuous Delivery with Visual Studio 2012
This is an excellent guide for transforming traditional and manual testing practices to support modern iterative development with continuous delivery.  This book is available as a free PDF.  Here are some highlights:

• Create and use effective unit tests, load, and performance tests.
• Record and play back manual tests to reproduce bugs and verify the fixes.
• Transform manual tests into code to speed up re-testing.
• Understand how the lab environment works and how it supports a project.
• Monitor your project in terms of tests passed.
• Run build-deploy-test workflows on virtual lab environments.
• Evolve your testing process to satisfy the demands of agile and continuous delivery.

Read More

 

Continuous Feedback using Storyboarding, Code Reviews, and the Feedback Tool in Visual Studio 2012 ALM
One of the key advantages of Agile or any other kind of iterative development process is to receive feedback early and often throughout the development process instead of waiting until the end. Traditionally this has been accomplished by teams working closely together where the decision makers can simply turn around to tell developers what they like and don't like. This type of collaboration becomes much more difficult with distributed development teams. Visual Studio 2012 has introduced several tools to help distributed teams collaborate better by being able to request, provide, and receive feedback throughout the development process.

Read More

 

Code Coverage in Microsoft Test Manager in Visual Studio Update 1
If you are QA professional, have you ever wondered how much of the application code is covered by your tests? Or if you are developer, have you ever wished you knew if there is any code that is no longer being called? Code Coverage for MTM makes it possible for QA professionals to know how much of the application code is being covered by Test Cases executed within MTM. Developers will know if all of code is being accessed by the application and a valid test case. Furthermore, developers can help the QA team identify scenarios in order to access the uncovered code blocks.

Read More

In TFS 2010 there is a lessor know feature to display work item state diagrams.  These diagrams map the workflow states and reasons of the work item.  This is very helpful to visualize and understand the the Work Item’s state workflow.  To view this in TFS 2010, you have to use Web Access to open a Work Item.  In the main toolbar there is the option like in figure 1.  This is not available from Team Explorer or Visual Studio.

Figure 1 – State Diagram button in TFS 2010 Web Access

In TFS 2012, this option has been removed from the Web Access work items.  However, you can still get to this if you are using SharePoint.  Within SharePoint, you can create Work Items and still access the State Diagram button.

Figure 2 – State Diagram button in SharePoint 2010 with TFS 2012

When you view the state diagram it should look similar to this.  Any customizations to the work items will be reflected in the diagrams.

TFS 2010 includes the ability to display the state diagrams of the work items.  These diagrams map the workflow states and reasons of the work item.  This is very helpful to visualize and understand the the work item’s state workflow.  The process template guidance includes similar diagrams however, if you have made any changes to the state workflow of the work item, the diagrams will reflect those changes and provide some guidance on the state workflow.

To view this in TFS 2010, you have to use Web Access to open a Work Item.  In the main toolbar of the work item there is the option like in figure 1.  This is not available from Team Explorer or Visual Studio.

Figure 1 – State Diagram button in TFS 2010 Web Access

In TFS 2012, this option has been removed from the Web Access work items.  However, you can still get to this if you are using SharePoint.  Within SharePoint, you can create Work Items and still access the State Diagram button.

Figure 2 – State Diagram button in SharePoint 2010 with TFS 2012

When you view the state diagram it should look similar to this. 

It is an exciting time to be doing development using Microsoft Tools.  Visual Studio 2012 has just been released to the web.  I have compiled a list of the most common questions I have received.  Keep the questions coming.  I plan on doing additional posts as I receive more questions.

Where and when can I download Visual Studio 2012 and Team Foundation Server 2012?

If you are a MSDN subscriber, you can download it right now.  Both of these have been available since 8/15.  If you are not a subscriber, you can download the Visual Studio Express or trial editions of the MSDN editions.
MSDN Subscribers
Express Editions, Stand-Alone installers, and Trial Downloads

Can I connect Visual Studio 2012 to TFS 2010?

Yes, you can use Visual Studio 2012 to connect to TFS 2010 and you can use Visual Studio 2010 to connect to TFS 2012.  Connecting previous versions of Visual Studio to TFS 2012 require a GDR Update.  The update and full compatibility matrix can be found here.
Compatibility between Team Foundation Clients and Team Foundation Server

Where is the Alerts Explorer in Visual Studio 2012?

Alerts in TFS 2012 are managed through Team Web Access.  Also, TFS 2012 now includes creating and managing Team Alerts. See the link below how to create Personal and Team Alerts.   If you are using TFS 2010, the Alerts Explorer has been a part of the TFS Power Tools through Visual Studio.  The TFS 2012 Power Tools have not been released yet but the beta tools did not include the Alerts Explorer.  If you need to manage alerts in TFS 2010, I would recommend still using VS 2010 with the TFS Power Tools.
Set Personal or Team Alerts in TFS 2012

Can I upgrade my TFS 2010 Team Projects to include the TFS 2012 Features such as Review, Feedback, and Planning tools?

Yes.  If you haven’t made any customizations or limited customizations to your TFS 2010 Team Projects, there is a built in tool for upgrading your team project.  Even if you have made some customizations, there are some more involved options for upgrading.  Here is a good post describing the options.
Use the wizard to upgrade team projects in TFS 2012

Why are not all of the new features in my TFS 2012 Team Project available?

Some of the new features in TFS 2012 require some additional configuration.  You won’t see the Request Feedback link until you configure email and not all of the features on Team Web Access are available until set the appropriate permissions.  The following link explains how to enable these features.
Enabling Feedback Requests, the Backlog and Sprint Planning Features in Team Foundation Server 2012

What licenses do my users need for PowerPoint Storyboards and the Feedback Client Tool?

For Storyboards, users with VS Ultimate, VS Premium, and VS Test Professional can use the PowerPoint add-in to create the storyboards.  Others with PowerPoint, can view and edit the Storyboards.  The Feedback Client Tool can be downloaded and used by any user.  This does not require a TFS CAL or MSDN Subscription.  All of the licensing details can be found in the Visual Studio 2012 and MSDN Licensing White Paper.   If you have questions, I recommend contacting your Microsoft representative for the most accurate answer.
Download Feedback Client for Microsoft Visual Studio Team Foundation Server 2012

What if I have more questions?

These are just a few questions. If you have other questions post them on the MSDN Forums.  There are of community experts that monitor these forums and provide answers.  Also you can email us at tfs@deliveron.com if you also have questions.  

Team Foundation Server 2012 includes a number of enhancements to Web Access for Agile Project Management and ALM process.  One of the new features allows you to update your Team Project’s landing page to include live tiles of important information called Team Favorites.  This provides a lightweight dashboard that is consistent in Team Foundation Service and on premise TFS 2012.  These Team Favorites can include the following:

• Work Item Queries
• Build Definitions
• Recent Changes

When you first display the Team Project Web Access site, you may see the message “Some features of Team Web Access are not visible to you” that states that some areas are not available because you either don’t have permission or the access has not be configured yet.  Web Access now has three permission levels:

• Limited – Provides the “View My Work Items” feature that replaces the Work Item Web Access (WIWA) interface in TFS 2010. This access does not require any kind of TFS license.
• Standard – Provides additional features including Agile Boards and Standard Features.  This access requires users to have a TFS CAL.
• Full – Provides additional features including Backlog and Sprint Planning Tools and Request and Manage Feedback.  This access requires users have Visual Studio Premium or Ultimate or Test Professional.

If all of your users are at least Standard or Full access, you can set this as the default permission or assign users or groups to these permissions.  See the following post on enabling the features and setting the permissions Web Access. Enabling Feedback Requests, the Backlog and Sprint Planning Features in Team Foundation Server 2012

Let’s assume you have a license to use the Full Permission.  Once you have this enabled, you will see the burndown chart and Iteration information (I’ll show you this at the end of the article). Below this is the Team Favorites section.  As you can see in the yellow message, there is where the live tiles will be added. 

I think it is going to be important for my team to know if there are any active bugs so they can be addressed appropriately.  Let’s add the Active Bugs Work Item Query to the Team Favorites.  To do this choose View work items link under Activities.  Then select the drop down triangle on the left of the Shared Queries > Current Iteration > Active Bugs query.  This will display the following dialog.  Chose Add to team favorites.

We encourage the developers on the team to check in often and it is important to have the visibility across the team.  To show this we will add Source Code activity for a particular branch.  In this example, I am adding the Main branch as the Team Favorite. Click on the SOURCE tab and then the drop down triangle next to the particular branch and choose Add to team favorites like above.

The last item I want to add to the Team Favorites is the build status of our Continuous Integration build definition.  This runs every time someone checks in the code so it is critical that this is always passing.  Providing this visibility helps ensure the quality of the application at any given time.  To do this, select the BUILD tab and then again follow the similar steps as above to add it as a Team Favorite.

Once all of the Team Favorites are selected, the team project landing page will display the live information.  Now our team has a single place to go to see the up to date health and status of our project.

Mike