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.

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

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. 

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.

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

TFS 2012 has been released to manufactures (RTM) and as of today (8/15/2012) it is available to download for MSDN subscribers.  TFS 2012 includes a number of enhancements that I will be writing about over the next few days and weeks.  Today, I’m going to focus on what is new in the installation experience.  The experience has improved enormously over the years and the latest version continues to polish an already intuitive and straightforward process.  I’ll walk through the experience and highlight the areas with key improvements or other noteworthy items.

I am using a Virtual Machine with Windows Server 2008 R2 to perform a single server installation of TFS 2012.  I have installed the following pre-requisites on the machine before beginning the installation process.

• SQL Server 2012
• SharePoint 2010 Foundation
• IIS Web Role
• MS Office 2010

See the TFSInstall.chm file on the DVD (see below) for pre-requisite requirements and installation steps.

Installation

First, let’s look at the installation DVD root folder. 

There are a couple things to note. 

• SharePoint Extensions are now called Remote SharePoint Extensions.  This should be helpful because it wasn’t clear in previous versions whether or not the SharePoint extensions needed to be installed on the same server with TFS.  The answer for TFS 2010 is the same for TFS 2012 and that you only need to install the extensions when SharePoint is on a remote server other than the same server as TFS. 
• Also the Project Server extensions that provide server to server integration/synchronization between Project Server and TFS is not included on the installation DVD.  This extensions was originally released after TFS 2010 and packaged as a Feature Pack.  Now there is nothing else to download.
• One other benefit of the new folder structure, is that you can simply run tfs_server.exe from the root to begin the installation process.  There are no more subfolders to search.

In TFS 2010, Microsoft separated the installation from the configuration.  This simplified many of the complexities and scenarios for setting up TFS.  With no surprise, Microsoft has kept that separation in TFS 2012.  The installation process begins with the typical installation start dialog.

This does require UAC administrative permissions to install.

While it was copying the files and running the installation, I noticed the TFS installation Windows 8 application style glyph (since we are not supposed to use the M word anymore…)

This completed the Installation step.  Next up is the configuration step.

Configuration

The TFS configuration tool gives you a number of options and settings for the various types of TFS configurations.  For this, I have chosen the Advanced option.  I personally prefer to choose the Advanced option in order to give me the most control.  The configuration tool also continues to provide options for configuring TFS Proxy, the Build Service, and the SharePoint extensions as it did with TFS 2010.  Two new options are the Visual SourceSafe Update tool and the PreEmptive Analytics Community Edition. I’ll cover the reasons for using each of the configuration options in one of my next posts.

The first step in the Advanced Configuration Wizard is specifying the database.  This step is very similar to TFS 2010 however, there is one new option to support the SQL AlwaysOn feature in SQL Server 2012

Here is some additional information available when you hover over the information icon.

Next is the Account settings. This is the same as TFS 2010.  Nothing interesting to show here.  Even though it isn’t necessary, I still recommend using domain accounts if installing on a domain.

In the Application Tier settings, you can change the default port and IIS Virtual Directory but nothing has changed from TFS 2010.

The next few screens are for Reporting.  These are all the same as TFS 2010 so I skip adding the screenshots and settings.

The SharePoint settings are next.  You can choose to install and configure SharePoint on the same machine from here or specify that it is already installed.  I already installed SharePoint, so I chose the later.  With that setting the next screen the asks for the Site URL and and Administrative URL for SharePoint.

The Project Collection settings are the last option. Choose I name for your default collection.  I kept the creative name, DefaultCollection.

Once all of the settings screens are completed, the configuration tool will run through the Readiness Checks and verify that TFS is ready to be configured.  My VM was a little short on RAM so I received a warning but everything else checked out.

Click Configure to run the configuration process and when it is completed, you should get a screen similar to this one.

As you can see the experience is similar to TFS 2010 which is great.  Most users should feel comfortable with this interface.  It also includes some nice improvements in areas to continue to make it more polished. Feel free to contact me if you have any questions about installing/configuring TFS 2012 or learning more about implementing it in your environment.

Mike

Have you downloaded the latest Visual Studio 2012 RC and Team Foundation Server 2012 RC and looking how to start taking advantage of all of the ALM features?  Look no further then the SIMultaneous SHIPping of the ALM Rangers Visual Studio 2012 RC Readiness wave of releases. This Readiness wave includes a number of guidance and tools to help you get the most out of Visual Studio 2012 RC today.  Download and start utilizing these releases!

Practical Kanban Guide

Practical Ruck Guide

Team Foundation Server Planning Guide

Team Foundation Server Process Template Customization Guide

Team Foundation Build Customization Guide

Team Foundation Server Upgrade Guide

Team Foundation Service Practical Guide

Test Release Management Guide

Visual Studio ALM Rangers Personas and Scenarios

Visual Studio Coded UI Microsoft Word Plug-In

Visual Studio Test Tooling Guide

Visual Studio Lab Management Guide

Visual Studio Quick Reference Guide

Visual Studio Architecture Tooling Guide

VM Factory Guide

and more coming soon!

All of the information is detailed on the Visual Studio ALM + Team Foundation Server blog.

We are trying to reach 500,000 downloads by the end of FY13.  Help yourself to all of this useful and practical information and help the ALM Rangers reach our goal! 

SQL Server 2012 was just launched and is packed a number of new features.  See the Microsoft SQL Server 2012 landing page for more information on SQL Server 2012.  SQL Server 2012 includes everything you need (almost, as I’ll show you below) to being utilizing the ALM features in Team Foundation Server 2010 without the developer edition of Visual Studio.  I’m going to walk you though the options to install, the configuration, and the additional downloads to begin using all of the features.

If you opened SQL Server Management Studio 2012 then you have probably noticed how it now powered by Visual Studio 2010.  In addition, the Business Intelligence Development Studio (BIDS) has been renamed to SQL Server Data Tools (SSDT).  Not only is SSDT powered by Visual Studio 2010, it now includes the Database Project template.  By integrating “Data Dude” (Microsoft’s original code name for the database development tools that keeps sticking) into the SQL Server installation, I think Microsoft is sending the message that ALM features for database artifacts are very important for database professionals and not just developers. 

SQL Server Installation

This first step is choose the proper features when installing SQL Server.  If you have already installed it without these features, you will need to rerun the installation and add these features.  During the Feature Selection of the SQL Server 2012 installation wizard, choose the SQL Server Data Tools and Management Tools to install the Visual Studio 2010 powered client tools as shown in Figure 1.

Figure 1 – Choosing the SQL Server Data Tools

Once this installation has completed, the two client tool programs will be available from the Microsoft SQL Server 2012 program menu.

Figure 2 – SQL Server Data Tools and Management Studio programs

Enabling Database Projects in SQL Server Data Tools

Open the SQL Server Data Tools and choose New Project. The Business Intelligence project templates are listed below for Analysis Services, Integration Services, and Reporting Services.  The SQL Server item has the option to install the additional functionality including for Database Projects.  Choose this option to download and install the additional functionality.

Figure 3 – Microsoft SQL Server Data Tools (Web Install) option

The dialog appears and provides the option to Install the features.  Click Install to take you to the link below.

Figure 4 – Installing Microsoft SQL Server Data Tools

The Get Started with Microsoft SQL Server Data Tools page includes the instructions for installing the tools for both Visual Studio 2010 Professional (or above) and SQL Server Data Tools.  The second bullet covers our scenario of the Visual Studio 2010 Integrated Shell and will download all of the required components from the link.  Click on the Download SQL Server Data Tools link to launch the Web Platform Installer 3.0 to install the SSDT application.

Figure 5 – Get Started with Microsoft SQL Server Data Tools

Click the Install Now link to run the Web Platform Installer powered installation.  Then click the Install button below to begin the installation process.

Figure 6 – Install Microsoft SQL Server Data Tools

Once the installation completes, you will have the Database Projects template available to use, however not all of the functionality that was included in previous versions of the Database Project is available.  The SSDT team is planning on using the SSDT Power Tools as a the delivery mechanism to continue to add functionality to SSDT based on the users requests and needs.  The first release of the SSDT Power Tools adds Schema View to the Database Projects.  Download and install the latest version the SSDT Power Tools to add this functionality. Continue to monitor this post and the SSDT Team blog for further improvements. 

Figure 7 – SSDT Power Tools Download Page

Finally, when you reopen the SSDT, the SQL Server Data Project template is now available.  You can now create Database Projects to manage your database artifacts with rich features such as smart rename and schema compare.  Furthermore you can leverage these projects to create automated builds and deployments to align with the application source code builds and deployments.  See my previous post, Implementing Continuous Integration (CI) and Deliveron for SQL Server Databases for some background on Database Projects especially for automated deployments.

There is one critical capability missing with this solution so far.  The Database Projects are important for following Configuration Management (CM) practices but it is not complete without the ability to use them with a Source Control Management (SCM) system.  Fortunately, by being powered by Visual Studio, SSDT can be tightly integrated with Team Foundation Server 2010 (TFS).   TFS 2010 provides a number of integrated ALM features including SCM and is even free to install if you have a MSDN license.

Figure 8 – Create SQL Server 2012 Database Projects

Connecting to Team Foundation Server 2010

The Visual Studio integrated shell that powers SSDT does not include the Team Explorer component that provides the full integration with TFS 2010.  Team Explorer is a free download (but requires a TFS CAL, also included with your MSDN license) that you can install to add this functionality.  Download and install Team Explorer 2010.  When the installation completes, you should download and re-install the Visual Studio 2010 SP1 (this was automatically installed for you).  To connect to TFS 2010, first make sure the Team Explorer view is visible.  If not go to the View menu and select Team Explorer.  In the Team Explorer toolbar, select the plus icon highlighted below to open the Connect to Team Project dialog and then select Servers to show you the Add/Remove Team Foundation Server dialog. Finally, click the Add button to create the connection to the appropriate TFS 2010 Server.  In addition to the SCM features with TFS 2010, this includes bug tracking, agile project management capabilities, build automation, test case management, and more.

Figure 9 – Connecting to Team Foundation Server 2010

I hope this provided the information you need get started using Database Projects with SQL Server 2012.  In a future post, I’ll go into detail on how to use the Database Projects.  If you are using the Visual Studio 2010 Professional or higher, the same link above will install the capabilities for this.  Finally if you are using the Visual Studio 11 beta or newer, the Database Project template for SQL Server 2012 is already included.  You will also want to download the SSDT Power Tools.

This was also cross posted on the Deliveron blog

In the weeks before the 2012 MVP Summit, I had been talking to colleagues and customers about feature requests and pain points in Team Foundation Server 2010 and Visual Studio 2010.  One the first day of the MVP Summit, I was reminded of the Visual Studio UserVoice web site.  This is a site where anyone can submit a feature idea and vote for existing ones.  Sign up for free and use your 10 votes to vote for your favorite ideas and/or create your ideas. Your votes do matter!

http://visualstudio.uservoice.com/forums/121579-visual-studio

I would still like to hear what you think.  Leave your favorites in the comments below.

Team Foundation Server 2010 provides functionality for testing applications with built in support for test plan and test case management    In our Agile/Scrum projects, we define all of the Test Cases in our planning meeting to define done for each User Story.  When starting new projects, team members often ask is how to format the Test Cases so they are clear.  One way we have found to be very useful is to use the same format as found in Behavior Driven Development(BDD).  BDD uses a format for communicating Test Cases called Gherkin.  The Gherkin format follows the pattern below:

Figure 1 – Given, When, and Then definition

Just like the User Story format (As a [user], I want to be able to do [business process], so that [business value]), we have found the Gherkin format is very useful for teams learning Agile.  In fact, these Test Cases can be written for Acceptance/Functional tests and for Unit Tests.  When we work with customers and our own projects we install our customized Deliveron Agile Process Template as part of the Deliveron Agile Delivery Process.  The Deliveron Agile Process Template is a slightly customized version of the MSF for Agile 5.0 process template.  In the Test Case work item, we have added fields for Given, When, and Then.  The “Then” should also match the expected result in the test steps.

Figure 2 – BDD additions for TFS Test Case Work Item

Figure 3 – Expected result matches the “Then”

Customizing the TFS Test Case Work Item Templates (WIT)  to add these fields is straight forward.  Follow the steps in this post I did a couple years ago.  It was for TFS 2008 but the steps are the same in TFS 2010.

In summary, use Test Cases to define done of the User Story and use BDD and Gherkin for the language of the Test Case.  Feel free to contact us if you have any questions about these changes or about the Deliveron Agile Delivery Process.

This has also be cross posted at http://www.deliveron.com/blog/post/Adding-BDD-to-the-TFS-2010-Test-Case.aspx

I recently worked with a client to create a fairly comprehensive solution for implementing Continuous Integration and Delivery for SQL Server Databases using Visual Studio 2010 Database Projects.  I had the opportunity to give a talk on the project at SQL Saturday in Omaha.  The presentation is here if you want the slides.  I think there is some context missing with the slides alone so I wanted to do this post to further explain the solution.

Before talking about the solution, let me describe three different continuous processes.  Continuous Integration (CI) is most familiar and is often used to describe all three of these processes.  I think the differences between these three processes is more clear by using these terms.

Figure 1 – Continuous Processes

Continuous Integration – Verifying code quality by compiling and running unit tests on the build server when a developer checks in changes.  Often abbreviated as CI.

Continuous Delivery – Adds the deployment of the application and database to an isolated test environment where additional integrated and UI automated tests can be run. 

Continuous Deployment – Includes automated deployment of the application through each environment through production.

In this post I will primary review our solution for CI and Continuous Delivery.  This works lays the foundation for the deployment into Staging and Production but I will discuss this in a future post.

Database Projects

Database tools in the past have been different than the tools used application code development.  These database tools have been difficult to implement change management practices and Application Lifecycle Management (ALM) practices.  Today there is an increasingly amount of application developers managing database changes.   These are some of the reasons that have led to need for a tool like Visual Studio Database Projects (DBPro for short).  This tool is part of Visual Studio 2010 (Premium and higher).  To create a Visual Studio Database Project, select SQL Server from the process template menu and then choose SQL Server 2008 Wizard or SQL Server 2008 Database Project.

Figure 2 – SQL Server Database Project Templates in Visual Studio 2010

The primary purpose of the Database Projects are to manage the the version control of database objects in SQL Server databases. The solution we established utilizes this and many of the features of DBPro including TFS Build Integration, Data Generation, Database Unit Testing, Static Code Analysis, and Database and Data Deployments.  In this post I’m not going to cover how to use all of these features but focus on how to implement the features for Continuous Integration, Delivery and Deployment processes.  For more information, please take a look at the Visual Studio ALM Rangers Visual Studio Database Guide .  This solution is complimentary to the guide and goes into more more specifics for CI.

Figure 3 – Visual Studio Database Guide

Challenges

Visual Studio Database Projects are a great tool and I highly recommend teams utilize these for managing version control for the SQL Server Databases.  However, successfully using Database Projects can be challenging.   I believe the benefits greatly out weigh the challenges but it is important for the team to be aware of these for a successful implementation.

Visual Studio – Visual Studio probably seems like an odd challenge considering this is the tool to use for the solution, however Visual Studio is a beast.  Visual Studio has become everything development.  Developers are used to Visual Studio and I have seen DBAs and other database professions get frustrated using it when they first start.  Stay with it.  It will get easier and is the future direction of Microsoft in SQL Server 2012.  From what I have seen SQL Server Management Studio 2012 is based on Visual Studio.

“Truth Center” Shift – Development teams have been used to using a shared database server and making changes directly on server since the stone age.  Managing source control of the database in DBPro essentially changes the “truth center” of the database project to DBPro.  Changes to the schema should be made in DBPro and then executed or deployed from DBPro to the shared server.  Development can also be done in local sandbox called offline schema development where the developer can make the changes locally and check them in.  Changes made directly to the shared SQL Server database risk being overwritten by the next deployment from DBPro.

Permissions – I have found DBPro does a great job managing almost all of the artifacts for databases.  The biggest challenge and frustration has been permissions.  The problem is that the database project holds the specific version of the database.  For permissions this doesn’t work in most real world examples because permissions change in each environment.  For examples, developers need different permissions in development versus what they need in production.  In addition, many enterprises use a separate domain for each environment.  As shown in Figure 4 below, Database Roles for the most part are consistent between environments and primarily the users and their role membership in those roles will vary.  The best method I found for handling these permission differences is to exclude them altogether.  Use the following steps to handle permissions when importing the schema and adding new objects to the project.  One advantage of removing the users is that that they are normally connected to a login and the login lives outside of the database in the Master database.  Including the users and logins in the project requires an additional project called SQL Server Server Project that contains the Master database.  This solution does not require a SQL Server Server Project.

Figure 4 – Managing Permissions Across Environments

Importing Databases

When using the importing the schema and objects into your project, make sure you perform the following steps to first import all of the permissions and the remove those that will change in different events.

• Enable Import permissions in the Import Wizard to import all of the permissions including Roles, Users, and Role Membership.
• After Import has completed:
  • Role permissions are to be kept in the .sqlpermissions file.
  • Schema Users (without login) are to be kept.
  • The other users must be removed
    • from sqlpermissions
    • From Security\Users
    • From RoleMemberships

Adding New Objects

When adding new objects in the Database Project

• Use Schema View
• Manually modify the Properties\Database.sqlpermissions and add the new permission
  • EX: Grant Execute to Role for Stored Procedures EXECUTE TestRole

            <
            PermissionStatement
            Action
            ="GRANT"
            >
            <
            Permission
            >EXECUTE</Permission><Grantee>TestRole</Grantee><ObjectName="spTestFromSSMS2"Schema="dbo"Type="OBJECT"/><Grantor>dbo</Grantor></PermissionStatement>

Permission Scripts

By removing the permissions from the project, there needs to be a place to account for these.  This solution accomplishes this by creating a script in the Scripts folder for environment that essentially creates the logins, users, and assigns the role membership for each user.  This allows the flexibility to store any variations between the environments and still store these in the database project and in source control.  Do not set the Build Action to PostDeploy because you can only have one for each project and it will be combined with the Deployment script.   Instead set the “Copy to Output Directory” property on the script to “Copy Always”.  This will create an Scripts folder and the permission files in the build output directory so it can be called by the deployment scripts.

Source Control

The primary benefit for using the Database Projects is that all of the database changes can be managed in source control.  There are a lot of ways to organize your source control and with branching and merging this can become complex to manage.  I like to take a pragmatic approach to source control and keep things simple but allow for complexity if needed in the future.  The Visual Studio TFS Branching Build 2010 is a great reference for adopting branching and merging strategy.  For this post I want to simply show the relationships between Production, Development, and Work Orders.  The main points is that the database projects should be branched and merged along side the application source control with some sort of release branch that has the current production version.  The Work Order branch is for production support changes that will be made into production.  Development teams should do downward merges often to always have any work order changes incorporated early.  When the application and database changes are deployed to production, the development branch should be merged up to the Production branch.  The diagrams below show how this is organized from a logic view and physical view.

Logical View

Figure 5 – Logical View of the Database Project Source Control Branches

Physical view

Figure 6 – Physical View of the Database Project Source Control Branches

Continuous Integration (CI)

To setup the most basic CI process for your Database projects, you can simply add the Solutions containing the database projects to your CI build that is building your application code.  The benefit of this is that it will build your database projects and validate that there are no schema errors and can validate any static code analysis rules.

Continuous Delivery

For Continuous Delivery, we want to expand the process to include deploying the database, insert any test data we need, and then run the database unit tests.  This adds validation that the schema in source control can correctly build the database and that stored procedures can pass any number of validations with the unit tests.  These steps would look like the following:

Figure 7 – Simple Continuous Delivery Process

Visual Studio Database projects make implementing this process very simple and only requires a couple simple settings.  The dialog below shows the out of the box settings.  To open this dialog, select Test > Test Configuration from the menu.   The sections are slightly out of order.  To start we want to set the Deployment database project to the project we want to deploy.  Next choose the configuration.  The configuration settings in the database project will specify the target connection string and other deployment properties.  Next, the Database state setting will generate the test data for the unit tests by running one of the data generation plans.

Figure 8 – Database Test Settings

Types of Continuous Delivery

The example above basically deploys the current version of the schema to the target but doesn’t is not a good practice run into production.   It basically deploys the changes from the last deployment.  My goal of the Continuous Delivery process should be a practice run into production and essentially deploy the application and database the way it will be done for the production deployment.   There are two types of delivery based on whether or not the application is already in production.  For new systems that haven’t been deployed to production, the deployment will be to deploy all of the schema.  This is referred to as Greenfield.  For existing systems, the schema will the difference of what is currently in production with what has been developed.  This is referred to as Brownfield deployments.

From a Visual Studio Database Project standpoint, Greenfield deployments are a simple using the deploy option.  This will drop the database and execute the full schema script to create the database.

Figure 9 – Greenfield Process

For Brownfield deployments in Visual Studio Database Projects, the process is accomplished in two steps using Production and Development versions of the database projects.  The first step is to use the Production version of the Database Project to create the full CREATE script.  Next, use the compare feature to compare the Production and Development versions to create the DELTA script.  Again, the key is not to compare the development against the live production database but to use the version of the Database Project that was created either from the production database or from the Release branch in source control.  Once you have these two database scripts, run the CREATE script to drop the database and create the database to the production level.  Then execute DELTA script to bring it to the current development level.  From there you can follow the similar steps to execute the data generation plan and automated tests to complete.  See below to see how this fits together

Figure 10 – Brownfield Process

Putting this all together, here are the steps in order for a good SQL Server database Continuous Delivery process.  There is some customization that has to be done for this.  The database testing options that were available for the simple process, won’t work out of the box for this solution.  This is because the Database Project doesn’t know about the production and delta scripts.  The build by default would create the database and run the data generation plan before unit tests including the database unit tests.  However, the unit tests are run immediately after the application is built and we need to specify the a step to build create the scripts and then execute them.  I customized the build definition by moving the unit test execution activities to later in the process so I could execute the SQL scripts before the Unit Tests are run.  Once this was moved, I could use the built in features to run the data generation plan.  Below are the steps for the full end to end Database Continuous Delivery process.

Figure 11 – End to End Database Continuous Delivery Process

To combine this process into the application continuous delivery process, the same tasks above can executed along with the application steps.  This process is grouped into three groups: Build/Stage, Deploy, and Execute Automated Tests.  The process is outlined below.

Figure 12 – End to End Application and Database Continuous Delivery Process

VSDBCMD

One of the great features of Visual Studio Database Projects is that the deployment and compare functionality can be executed via a command line utility called VSDBCMD.exe.  This allows us to perform the necessary steps in our Continuous Delivery process.  I utilize a InvokeProcess Activity in the build definition to call a PowerShell script to execute the VSDBCMD commands.  Below are examples of how to create the Production CREATE script and the DELTA script.  The Production Script creates the full CREATE script from the compiled Production version of the Database Project.  The DELTA command shows how to compare two Database Projects to generate the DELTA SQL Script.

Create Production Script

& "C:\program files (x86)\Microsoft
Visual Studio 10.0\VSTSDB\Deploy\vsdbcmd.exe"

/a:deploy /dsp:sql /model:Ecommerce.dbschema /DeploymentScriptFile:c:\temp\OutputFilename2.sql 

/p:TargetDatabase="NewEcommerce"

Create Production and Development Delta Script

& "C:\program files (x86)\Microsoft
Visual Studio 10.0\VSTSDB\Deploy\vsdbcmd.exe"

/a:deploy /dsp:sql /model:Ecommerce.dbschema /DeploymentScriptFile:c:\temp\OutputFilename2.sql 

/targetmodelfile:"C:\tfs\deliveron\Production\EcommerceSolution\Ecommerce\obj\Debug\ecommerce.dbschema"

/p:TargetDatabase="NewEcommerce"

In Summary

This concludes the overview of the solution for Continuous Integration and Delivery for SQL Server Databases.  I hope it gives you a complete overview for creating your own Continuous Delivery process.  Feel free to contact me if you have any questions or comments.

Review of Key Concepts

• There are three types of Continuous processes: Integration, Delivery, and Deployment.
• Continuous Delivery should be set up to be a practice run for Production.
• Create compare scripts between development and production database projects and don’t compare against live databases.
• VSDBCMD is a command line utility that perform the deployment and compare functionality in Visual Studio Database Projects.

This was also cross posted at http://www.deliveron.com/blog/post/Implementing-Continuous-Integration-(CI)-and-Delivery-for-SQL-Server-Databases.aspx

If you have ever tried scripting database schema and data from SQL Server, you have probably been frustrated like me that there is not a simple process for doing this.  SQL Server Management Studio includes two options highlighted below.  The Generate Scripts… option works as expected and allows you to easily create a script to recreate the database.  However, if you want to export the data to import it at a later point, using the Export Data… option doesn’t quite do what is needed to script the data.  It allows you to script to a CSV or Excel file, however I have found importing an exported file, isn’t always easy.  

Figure 1 - SQL Server Management Studio

Surprisingly there is a better option not in SQL Server Management Studio but in Visual Studio 2010 (I believe this option is available in Visual Studio 2008, but I wasn’t able to confirm this for the post.).  Visual Studio 2010 includes an view window called Server Explorer.  This is typically used for data binding and tools like LINQ and Entity Framework.

Figure 2 – Visual Studio 2010 Server Explorer

The context menu for the particular data connection includes an option called Publish to provider… 

Figure 3 – Publish to provider

This option launches the Database Publishing Wizard.  When this wizard displays it gives you the option to export both schema and/or data to a SQL file.  Especially for data, this is perfect for migrating data from one environment to the next including preserving identity keys.

The wizard opens with the option to choose a database and automatically script all objects in the selected database.  I chose the AdventureWorks database and clicked Next.

Figure 4 – Select Database in the Database Publishing Wizard

The next step in the wizard is to choose what objects types to publish.  Here I select Tables.

Figure 5 – Choose Object Types in the Database Publishing Wizard

With the the Tables option selected in the previous step, the Choose Tables step appears.  Here I selected a single table for this demo.

Figure 6 – Choose Tables in the Database Publishing Wizard

Finally choose the output location.  This can either output to a file or to a hosting provider.  Here I chose the Script to file option to save the output to a file.  To use the Publish to shared hosting provider your hosting provider or target system must support a SQL Publishing Web Service and the database already exist on the target.

Figure 7 – Select an Output Location in the Database Publishing Wizard

This screen includes the publishing options.  The options are straight forward.  The Drop existing objects in script option will toggle a dropping existing objects in the target database before the new objects are scripted.  The Schema qualify option qualifies object names with the schema.  The Script for target database drives the compatibility of the script.  Finally the Types of data to publish allows for schema or data only or both.  Here I want to script both so I chose Schema and data.

Figure 8 – Select Publishing Options in the Database Publishing Wizard

The final screen is a confirmation of the options selected.  Click Finish to run the wizard and create the script.  When the wizard completes, it will display success.

Figure 9 – Successful Database Publishing Wizard

Below is the output of the Database Publishing Wizard for the schema and data.

Figure 10 – Schema output of the Database Publishing Wizard

Figure 11 – Data output of the Database Publishing Wizard

For more information on the Database Publishing Wizard, read Deploying a Database by using the Database Publishing Wizard on MSDN.

This was also cross posted at http://www.deliveron.com/blog/post/Script-Database-Schema-and-data-using-Visual-Studio-2010-and-Database-Publishing-Wizard.aspx

Enjoy!

Mike Douglas

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] publicvoid 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=179463this.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] staticpublicvoid ClassInit(TestContext
context) { Playback.Initialize(); try { sharedTest.OpenCustomerKeeper();
} finally { Playback.Cleanup(); } }

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

[ClassCleanup] 
staticpublicvoid 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