If you’re in SoCal somewhere, you may want to take advantage of this FREE “quick start” event, offered by HarborObjects.

For registration and additional details, visit their events page, but below is a teaser of what you’ll learn during this event:

The goal of this training is to quickly bring you up to speed with the essentials features of Team Foundation Server 2010 so that you can quickly setup and be productive in your own TFS environment.

We start out by outlining a generic development process which embodies basic activities that are encountered in any software development process.  We'll use those activities as the context in which you'll learn to use TFS and you'll be able to easily map those activities into the process that you use in your own development work.

2012 Event Dates:

• January 11th - Microsoft Office, Los Angeles
• January 18th - Microsoft Office, San Diego
• January 25th - Microsoft Office, Orange County

Again, visit the events page to register, and we hope to see you there!

TFS Preview is just that – a preview.  So things may not be where you’d think they are, especially if you’re used to the current version of Team Foundation Server.

I was recently asked (twice), “Okay, so I’ve got my account and project collection established, how do I get more people added to the environment so we can do some team development?”

Here’s the quick way:

1. Log in to your TFS preview site (https://<whatever>.tfspreview.com)
2. Click on Collections at the top, and select the collection (most likely “Default Collection”) to which you want to add users.
3. You’ll see a list of Team Foundation groups at the left.  Select the group (or create a new one) to which you want to add users.
4. You’ll see information about the selected group at the right.  Click the “add members” link under Group Membership.
5. In the dialog, enter:
1. An email address of the user to add, if they are not already in the system.  Remember that this email address needs to be a Live ID, as currently that’s the only authentication type supported for TFS Preview.
2. The display name (select from the drop-down list) of the user to add, if they already exist in the system.
6. Click “Save Changes”
7. Send the user the URL (https://<whatever>.tfspreview.com) and have them log in with their associated Live ID, and they should be set.

For a broader overview of setting up groups, users, and security, I recommend taking a look at this video tutorial.  There are several other video tutorials that you can watch, all from the Administration page on your TFS Preview site.

I receive a lot of email each week from you asking very specific, and valuable questions. It’s my hope that a newsletter like this will help me communicate important announcements, tips/tricks, and other items to help you and your team ultimately be more successful!

Upcoming Office Hours

Yep, I’ve added virtual office hours to my plate in an effort to get your questions answered!  I’m holding them for an hour every 2-3 weeks – I hope you stop by sometime!  My next office hours are next Friday, 11/18 at 9:30am Pacific.

Announcements

If you’re using using Visual Studio 2010 and TFS 2010 (and possibly Test Professional 2010), you may want to download and take advantage of the “Visual Studio 2010 SP1 TFS Compatibility GDR” update, now available.  It contains several fixes, and even the addition of a highly-requested feature in MTM (multi-line test steps)! 

The OData Service for Team Foundation Server 2010 is not officially released!  Brian Keller has more here.

If you’ve been playing with the VS 2010 virtual machine with labs and sample data, it’s been refreshed with a new expiration date.  Again, see BrianKel’s blog for details.

Did you know you can “fake” a TFS build? This is useful if you don’t actually use TFS as a build system, but still need build numbers to load into TFS to help associate items together (i.e. changes between “builds” for testing purposes).

Want to get access to TFS Preview but don’t have an invite code?  Ping me, let’s talk.

Are you going to the ALM Summit next week in Redmond?  I am, and I hope to see you there!

Upcoming

November 17, 2011 Coffee Talk: Scrum-damentals (free webcast)

November 28, 2011 LIVE event in Edina, MN: Double Feature: Testing & ALM for Agile Development For Details or to Register, Click Here

November 29, 2011 LIVE event in San Diego, CA: Double Feature: Testing & ALM for Agile Development For Details or to Register, Click Here! 

November 30, 2011 Visual Studio 2010 ALM Tools Live Roadshow
Denver, CO

Don’t Forget!

My team has access to programs (and funds to help pay for them) to help you and your organization get ramped up on all sorts of topics and technologies:

• TFS Deployment Planning Services
• Productive adoption of Microsoft’s ALM Platform – ALM Catalyst
• InnerWorkings

Send me a note and let’s see where I can help!

QuickAnswers

• In MTM, if you don’t see test results not showing up in the “Analyze Test Runs” area in MTM, it’s usually because either a test run isn’t actually completing a test run (i.e. exiting a test run without saving), or not filtering the view properly (this is most common). Try setting the “Start date range:” filter to “All”, and try toggling the “Show manual runs” button to see if your rest run results show up.
• BIDS and Visual Studio 2010 are separate products, and while there is definitely overlap in functionality (schema object creation, for example), with BIDS being based on Visual Studio 2008 there are several areas that are specific to BIDS that Visual Studio 2010 will not do (and vice versa, for that matter).  The simplest way to differentiate between the two is that because BIDS is based on VS 2008, support for the below project types are only supported in BIDS: BIDS Integration Services, Report Services, and Analysis Services.  Many customers simply use Visual Studio 2010 Premium or Ultimate side-by-side with BIDS, so that SSAS packages (for example) can be worked on in BIDS, and other object creation, change management and testing functions can be performed in VS 2010.
• When you remove a test case in MTM, the test case is not physically removed from the system but rather disassociated from its test suite. That’s why it will still show up on the Organize tab. This helps you identify overall test volume, and find potential test cases created by others that should be included in your test plan. Click here for more information.
• Want to export information from MTM?  You have a few options.  First, you can use TestScribe, a free add-in for MTM that allows you to generate documentation for either a test plan or test runs.  You can also export your test cases to Excel, either from Team Explorer or by using Excel itself. For more, see: Create, Open, and Modify Work Items Using Office Excel or Refresh Work Items and Change the List Type in Office Excel.  Finally, in Team Explorer (and in TFS Web Access, our browser-based client), you can elect to print one or more test cases directly from TFS. See: Print Work Item Results or Forms

Parting Thought

Why is 'abbreviated' such a long word?

Team Foundation Server’s build system serves as the “heartbeat” for your development lifecycle.  It automatically creates relationships between code changes, work items, reports, and test plans.

But once in a while I’m asked, “What if we don’t use TFS Build for building our application, but we still want to have builds in TFS so we can track and associate work?”  Besides the biased question of “Why NOT use TFS Build, then?!”, there is sometimes the need to leverage the benefit of having empty/fake builds in TFS that don’t do anything more than create a build number/entry in TFS.

There are a couple scenarios where this makes some sense, but the most common one I hear is this:

• The dev team uses TFS for version control and work item tracking, but NOT builds.
• The QA team wants to use Test Professional (or more specifically, Test Manager) for its test plans, and be able to see what features or bugs need to be tested against over time.

Without builds in TFS, it’s near impossible (or at least very inconvenient) to tie test plans (accurately) to the rest of the lifecycle.

Luckily, TFS 2010’s build system is incredibly flexible: flexible enough to allow us to “fake” builds without actually performing build actions (get source, compile, label, etc.).  It’s surprisingly simple, actually; and it doesn’t require writing any code.

In my example (which I’ll detail below), I define a build which doesn’t do much more than craft a build number and spit out some basic information to the build log.

First, create a new build process template, based on the default process template, using the steps described in this MSDN article.

Once you have the process template created and registered in TFS, open the new template (.xaml file) in Visual Studio.  It will look (collapsed) something like this:

Here’s where it gets fun.  Inside the outermost sequence, delete every sequence or activity except for “Get the Build”.

Drag an UpdateBuildNumber activity from the toolbox into the sequence, after “Get the Build”.

(optional) Rename “Get the build” to “Get Build Details” so there’s no implication that an actual build will take place".

Now expand the Arguments section (at the bottom of the XAML Designer window).  Delete all arguments except for BuildNumberFormat, Metadata, and SupportedReasons.

At the bottom of the now-shorter list, use “Create Argument” and create the following arguments:

“MajorBuildName” and “MinorBuildName” will be used to help manually name each build.  “Comment” will be used to capture any notes or comments the builder wants to include for a given build.  “IncludeBuildDetails” will be used to determine if additional summary information about the build will be written to the build log.

To provide users with means to set values to these arguments, create parameters in Metadata.  Click the ellipsis (…) in the Default value column for Metadata.  This will bring up the Process Parameters Metadata editor dialog.  Add each of the following parameters:

A couple notes about setting the above parameters:

• The “parameter name” should match the name of the like-named argument.
• Use the exact same category name for each parameter, unless you want to see different groupings.  Also, check for any leading or trailing whitespace, as the category field is not trimmed when saved.
• Feel free to add descriptions if you like, as they may help other users understand what to do.
• Leave the “Editor” field blank for each parameter.

Your dialog should now look something like the one at right.

Next, open the expression editor for the Value property of the BuildNumberFormat argument and edit the value to read: “$(BuildDefinitionName)_$(Date:yyyyMMdd)_$BuildID)”. Including the BuildID will help ensure that there is always a unique build number.

Now, Click “Variables” (next to Arguments) and create a new variable named ManualBuildName of type String, scoped to the Sequence, and enter the following as the Default:

If(String.IsNullorEmpty(MinorBuildName), MajorBuildName, MajorBuidName & “.” & MinorBuildName)

This variable will be used to provide a manual build name using the supplied MajorBuildName and MinorBuildName arguments.

Now we have all the variables, arguments, and parameters all ready to go.  Let’s put them into action in the workflow!

Drag a WriteBuildMessage activity into the main sequence, before Get Build Details, with these settings:

• Display name: “Write Build Comment”
• Importance: Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High
• Message: “Comment for this build: “ & Comment

Next, add an “If” activity below “Get Build Details” to evaluate when to include additional details in the build log, with the following properties:

• Display name: “Include Build Details If Chosen”
• Condition: IncludeBuildDetails

In the “Then” side of the “If” activity, add a WriteBuildMessage activity for each piece of information you may want to include in the build log.  In my example, I included 3 activities:

Your “If” activity will look like this:

The last thing to do is to add an UpdateBuildNumber activity as the last element in the main sequence, with the following properties:

• Display name: “Set Build Number”
• BuildNumberFormat: BuildNumberFormat & “-“ & ManualBuildName

This last activity will actually create the build number which will be stored back into TFS.  Your completed workflow should look like this:

Now go back to Source Control Explorer and check this template back into TFS.

Go create a new build definition, opting to use your new template on the process tab.  You’ll notice that your options are dramatically simplified:

Specify a value for Major Build Name and save your new definition. 

Queue the build and you’ll see the following on the Parameters tab:

Enter some basic information and click “Queue” to run the (fake) build.

What you end up with is a build that completes in just a couple seconds, does pretty much nothing, but includes your specified information in the build log:

Pretty sweet!

And just to be clear, my example adds more “noise” into the build than you may find necessary, with additional build information, comments, etc.  You could streamline the build even more by removing the “Include Build Details If Chose” activity (and all its sub-activities).

Given the overall flexibility TFS 2010 has with incorporating Windows Workflow into the build system, there are undoubtedly other ways to accomplish variations of this type of build template.  But I had fun with this one and thought I should share.  I’ve posted my sample template’s xaml file on SkyDrive here:

I’m all ears for feedback!