For quite a while, the Developer Division at Microsoft continued to use their internal build systems to build Visual Studio.  TFS Build had only been used by certain teams within the division but not standard across the division.  I had the opportunity to visit one of the huge build labs last time I was in Redmond and it’s impressive.  It was just one of them too.   I really got an appreciation for the complexity that was involved in building .NET, Visual Studio, and Team Foundation Server.   We’re talking huge builds that take up a lot of time.

Brian Harry just mentioned that they had hit a huge milestone for the division during their MQ phase and have gotten a build to run through the TFS 2010 Build system!  Sounds like they still have some work to go to get it tuned but getting a Visual Studio build through TFS Build is huge accomplishment!  Looks like they have even taken some of the experiences they gathered and already integrated improvements into the next version of the product.  That just benefits all of us as customers whenever Microsoft is eating their own dogfood. 

Congratulations!

Ed Blankenship

One of my favorite new build workflow activities is the FindingMatchingFiles activity.  It’s an activity that is provided out of the box for use during Team Build that returns an IEnumerable<string> of all of the files that match a particular wild card string.

It’s available in the toolbox under the Team Foundation Build Activities tab.  The full name of the activity is:  Microsoft.TeamFoundation.Build.Workflow.Activities.FindMatchingFiles.

Here is a typical usage if you are looking for all .CSS files in a particular folder.

The problem I was attempting to solve is how to find all of the files recursively in all of the subfolders as well.  All I had to do was change the match pattern argument to include a “**” in front of the original pattern and it worked like a charm!

Ed Blankenship

I’ve been hitting my head against the table today trying to have a nice experience for editing a collection of string values as a custom build process parameter in my TFS 2010 build definition.  The problem comes with what editor is actually used to edit the process parameter at design time.  You can specify a custom editor for any of your custom build process parameters which is really handy but I needed the ability to use editors that were out of the box but still provided a sufficient experience to the end user.

My journey towards a solution…

Attempt 1

I began really wanting to have one build process parameter that had the type of Dictionary<string, string>.  That didn’t work out so well because when I went to edit it in my build definition, I received this editor and the add/remove members buttons.

Attempt 2

I gave up on the Dictionary<T, T> approach and decided that I could handle it by specifying two collections of type Collection<string>.  I also attempted to try List<string> and even a String[] but ended up with this editor that seemed to not like System.String.

Attempt 3

I found Microsoft.TeamFoundation.Build.Workflow.Activities.StringList.  It is a custom type that is known to Team Build 2010 and even has a custom editor that is registered to it that shows up.  That editor is Microsoft.TeamFoundation.Build.Controls.WpfStringListEditor.  Works great for me!  Take a look:

Ed Blankenship

Looks like this past weekend Don from Microsoft Learning announced the public availability of the Team Foundation Server 2010 Microsoft certification exam.  I had several people ask about what happened to the Beta exam for 70-512 and the only thing I can see is that it was released directly to the public without a Beta phase.

If you pass this exam, you will receive the Microsoft Certified Technical Specialist certification for TFS 2010.  Officially it will indicate:
MCTS: Visual Studio 2010 Team Foundation Server, Administration

I’ll be taking the exam this weekend so I’ll let everyone know how it goes.  Well… as much as I can!  Exam candidates agree not to disclose details about the exam when they take it.

There aren’t any preparation materials available just yet as listed on the Exam Details site.  It does however list the topics that are covered on the exam:

About this Exam

This exam is designed to test the candidate's knowledge and skills on installing, configuring and maintaining Visual Studio 2010 Team Foundation Server.

Audience Profile

This exam is intended for candidates who install, configure, and manage a Microsoft Visual Studio Team Foundation Server (TFS) 2010 implementation. Candidates typically work in an enterprise development organization that provides process automation services by using TFS.

The qualified candidate has:

• a solid understanding of the TFS architecture and components.
• experience installing and configuring a TFS in both single-server and multi-server configurations.
• experience managing security for TFS components.
• experience configuring and using Team Build.
• experience adapting process templates to an organization.
• experience managing project artifacts with TFS version control.
• experience configuring and using work item tracking.

Skills Being Measured

This exam measures your ability to accomplish the technical tasks listed below.The percentages indicate the relative weight of each major topic area on the exam.

Installing and Configuring TFS (27%)

• Install TFS.

  This objective may include but is not limited to: SQL Server version support, installing TFS in a multi-tier or multi-machine environment, installing TFS in a load-balanced environment, setting up version control proxy

• Configure application tier

  This objective may include but is not limited to: validating an installation, configuring SMTP for TFS, changing the URL (friendly name), changing the default SharePoint Web application, setting up reporting (SQL Server Analysis Services)

• Migrate and upgrade TFS.

  This objective may include but is not limited to: upgrading TFS 2005 or TFS 2008 to TFS 2010, importing a source base from Microsoft Visual Source Safe (VSS), a third-party revision control system, or a sub-version

• Install and configure team lab.

  This objective may include but is not limited to: set up environment templates, installing and configuring test agents, installing and configuring Virtual Machine Manager (basic Virtual Machine Manager installation), creating library shares or resource pools

• Install and configure multiple build agents and controllers.

  This objective may include but is not limited to: tagging, binding a controller to a project collection, adding as build agent

Managing TFS (27%)

• Manage Team Project Collections.

  This objective may include but is not limited to: moving project collections, managing team collections and projects, creating and configuring team project collections, moving team projects from one collection to another, creating a team project with SharePoint and SQL Server Reporting Services, cloning (splitting team project collections, partitioning)

• Configure for backup and recovery. 

  This objective may include but is not limited to: backup and recovery of TFS and related components, recover a failed application tier, recover a failed database tier, implement a disaster recovery plan

• Monitor server health and performance.

  This objective may include but is not limited to: application tier logs, monitoring the server for performance issues (monitoring activity logging database and TFS server manager), monitoring job infrastructure for failed jobs (monitoring warehouse adapters and warehouse jobs), cleanup of stale workspaces and shelvesets, cleanup builds (applying retention policies), setting up team build to use a version control proxy server

• Administer TFS application tier.

  This objective may include but is not limited to: retiring or archiving projects and purging the system, rebuilding a warehouse, configuring user permissions by using Active Directory Domain Services  and TFS groups, moving a TFS instance to a new server or a new domain, configuring security for TFS Work Item Only View

• Manage reporting for TFS.

  This objective may include but is not limited to: basic reporting using Microsoft Office Excel Services, adding a custom report to a SharePoint project portal, uploading a new SQL Server Reporting Services TFS report, configuring to enable a report to appear in a SharePoint project portal

• Set up automated functional and UI tests.

  This objective may include but is not limited to: setting up a build definition, configuring the build definition to use the proper lab environment, setting up tests to work on an installed agent, setting up a service as interactive, setting up data collectors

Customizing TFS for Team Use (24%)

• Configure a team build definition.

  This objective may include but is not limited to: setting up for a Symbol Server and Source Server, setting up for test impact analysis, setting up for custom build numbers, configuring build log verbosity, setting up for code analysis, setting up for automated unit testing, setting up for architecture validation

• Configure and execute a build. 

  This objective may include but is not limited to: queuing a build with parameters, reconciling workspaces as part of a gated check-in workflow, setting up build triggers (gated check-in, continuous integration, scheduled build)

• Modify a process template.

  This objective may include but is not limited to: customizing a process template by changing the workflow for a work item, adding a new work item type as a child of an existing work item (WI), uploading and downloading process templates

• Configure a team project.

  This objective may include but is not limited to: areas and iterations, default security groups, portal settings (team project portal site URL, process guidance URL)

• Apply work item customizations.

  This objective may include but is not limited to: link types, Global list, creating a new WI category and adding existing WI types to the new category, adding or removing fields, transitions, queries, customizing a workflow, creating or editing a work item type, importing and exporting work item types, renaming work item types

• Create Work Item Query Language (WIQL) queries.

  This objective may include but is not limited to: query folders and permissions, query types (tree, flat, directed), defining WIQL keywords, adding fields to a query, creating a WIQL query by using Team Explorer, identify built-in macros

• Configure client connectivity to TFS.

  This objective may include but is not limited to: configuring Visual Studio, Team Explorer, Microsoft Excel, Microsoft Project, and other tools to connect to TFS, configuring clients for proxy server

Administering Version Control (23%)

• Create and manage workspaces.

  This objective may include but is not limited to: cloaking, undo delete, modifying a workspace, deleting a workspace, specifying the workspace visibility, restoring deleted items, unlocking other users’ checkouts, pending changes, and code

• Configure shelvesets. 

  This objective may include but is not limited to: private builds, creating a shelveset, deleting a shelveset, opening another user’s shelveset

• Branch and merge source artifacts.

  This objective may include but is not limited to: track change visualizations, converting a folder into a proper branch and creating a new branch, merging and resolving file conflicts, viewing branch hierarchy, creating a branch, deleting a branch

• Configure version control proxy.

  This objective may include but is not limited to: cache hit ratio, setting up the cache size, setting up for multiple TFS servers

• Configure team project version control settings.

  This objective may include but is not limited to: enable multiple checkout, enable get latest on checkout, configuring check-in policies for a team project (work items, builds, code analysis, testing policies)

Good luck!  Let me know how you end up doing on the exam.

Ed Blankenship

During the first week of April, a little package was sitting on my front porch with the first book to be released on the Visual Studio 2010 release that deals with the new Application Lifecycle Management (ALM) features.  For those of you who don’t know, this essentially means the former “Team System” line of products as we were exposed to it in the 2005 and 2008 releases.  Although the entire Visual Studio suite of products is considered something that helps you with ALM, the book primarily focused on Visual Studio 2010 Ultimate, Visual Studio 2010 Premium, Visual Studio 2010 Test Professional, Visual Studio 2010 Lab Management, and Team Foundation Server 2010.  During the Introduction, I even appreciated how the authors discussed about “where Team System went.”  It’s the best explanation of the branding change that I’ve seen to date.

I was extremely excited to start immediately reading the book.  Even though I have been closely involved with the 2010 release as a Microsoft MVP, when I started to read this book my goal was to be exposed deeper in the feature set being introduced in the 2010 release.

At the time of writing this blog post, the book was selling for $34.64 at Amazon.  The suggested retail price is $54.99.  It is currently #7 in the Software Development books category!

Strengths

If you are new to the ALM features in Visual Studio, I felt this book really offered you the ability to get the high-level overview of all of those features.  It’s essentially similar to a “survey” course that you would have taken in college.   It’s 696 pages that ends up going through all of the Visual Studio client and server features at just the right level of detail. There were even some areas that I felt that I learned more about and hadn’t been exposed to heavily in the past.

The architecture features were something that I had hoped to learn the most from.  They have just never been something that I dived into great detail during the 2010 release cycle.   All of the new UML diagrams that are available including the new architecture features like Use Case, Activity, Sequence, Component, Class, Dependency, and Layer Diagrams.  There was a also a great introduction to the Architecture Explorer.

The testing features have really been what has made up a majority of the Visual Studio 2010 release and the book definitely reflects that.  Going through the testing features, I really felt like I understood the end to end story.  It felt very rounded out!  These chapters are where I picked up a majority of the nuggets of information.  I can’t tell you how many times I said “wow, I didn’t know you could do that.”  I also feel like this is a great place to pick up some introductory knowledge about how Visual Studio Team Lab Management fits into the ALM story.  I also kept thinking how great this book would be for the testers on your team that are new to the Microsoft testing platform and Team Foundation Server.

There are so many changes to TFS, I can’t even begin to start describing them.  Thankfully, the book did a great job.  Especially with the revamp of Team Build to use Windows Workflow Foundation.  You can even download the Team Build chapter from the book for free here:  Team Foundation Build.  Other than automated builds, you’ll get a good pass by all of the rest of the new TFS 2010 features and architecture/topology changes.

There was a whole chapter dedicated to debugging with IntelliTrace!  That’s awesome.  I’m very much a fan of IntelliTrace and think that will truly change the way you develop.

Criticisms

I have been hoping to have a book available out there that really only discusses TFS.  The book definitely has a few chapters available on TFS and spends a good amount of time but that discussion is not the nitty gritty that I think some readers out there are really looking for.  With that said, I don’t think this book was positioned for the “TFS Administrator” exclusively.  Again, I really think this is a survey-level review of the entire ALM stack of features for Visual Studio.  That doesn’t allow you to go into the depths of any particular product.  There currently isn’t a book available for TFS 2010 with the level of detail that I am sure some readers out there are hoping for.  We’ll see what happens in the months to come…

My next criticism isn’t so much for the content of the book as what is media choices are available.  I own a Kindle DX and I imagine a few other techies in the world have some type of eBook reader as well.  I was hoping to have a CD that contained a DRM-free PDF that I could copy over to my Kindle DX whenever I’m traveling and need a quick resource for reference.  Wrox certainly does allow you to get a PDF of books but you have to order them separately even if you had purchased the hard copy.

Finally, the only other thing that I noticed was in that chapter about IntelliTrace (see above) there wasn’t a mention of Symbol & Source Server.  I couldn’t believe it.  There is definitely a discussion later in the book about Team Build’s integration with Symbol & Source server but I was hoping to have seen some more detail in the IntelliTrace chapter about the importance of having them setup for your organization.  You’ll want to put two and two together.

Now that I’m finished scrounging from the bottom of the barrel to find some criticisms… :)

My Recommendation

Hands down, get this book.  I think it’s well worth it.   I know each of the authors and it really looks like they put a tremendous amount of effort into writing the book.  The topics are really presented well and at the right level of detail for someone really wanting a crash course in all of the Visual Studio ALM features.  I can’t even tell you how many new nuggets of information that I ran across of things that I didn’t even realize were in the product.

It certainly gets my stamp of approval! :)  Kudos to the authors.

Very respectfully,

Ed Blankenship

Microsoft MVP of the Year, Visual Studio ALM and Team Foundation Server

Not sure if you have seen this but some of the product managers on the TFS Build team at Microsoft have been putting together some great blog posts for how to create custom build activities and get a little background about Windows Workflow 4.0 and how it relates to TFS Build 2010.

• How to Create a Custom Workflow Activity for TFS Build 2010 by Jim Lamb
• Windows Workflow 4.0 – CopyDirectory (Part 1 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyDirectory (Part 2 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyDirectory (Part 3 of 3) by Patrick Carnahan
• Windows Workflow 4.0 – CopyFile by Patrick Carnahan
• Writing Custom Activities for TFS Build 2010 (Beta 1) by Aaron Hallberg
• Display Custom Build Information by Jason Prickett
• Modifying the Default Display of Build Information by Jason Prickett

Also, we’ve been trying to put together a CodePlex project that’s designed to be a central location for contributions of Team Build 2010 customizations like custom activities, build process template customizations, build tools, etc.  You can take a look here:  http://teambuild2010contrib.codeplex.com/.  I’d encourage you to think about contributing any of your customizations to this project.  I know I’m personally hoping that it will be the “go-to” place for some of the common build activities that people need.  If you happen to have any feature requests for build activities, feel free to request one in the discussions and we’ll add it to the backlog:  http://teambuild2010contrib.codeplex.com/Thread/List.aspx

Thanks!

Ed Blankenship

In Team Foundation Server 2010, you know have the ability to (easily) have multiple build agents on the same build server.  You were able to do this in TFS 2008 but it really wasn’t supported.  However, this raises an interesting challenge:  some processes and executables aren’t designed to handle being run simultaneously in multiple contexts on the same build machine.  Some applications can’t or have a difficult time handling concurrent access from multiple build servers at the same time as well.

I’ve listed a few of the scenarios that I can I remember off the top of my head:

• Automated UI Testing – running automated UI tests from two different builds on the same build machine can lead into utter confusion!  :)  Mouse clicks going everywhere!  Let’s just stick to one set of automated UI tests running on an individual machine at the same time.
• Running Automated Tests that Collect Code Coverage Information -  This was an interesting limitation that I found in the 2008 release.  It seems that the code coverage data collector did not support collecting from more than one automated testing run happening concurrently on the same machine.  (This might actually have been addressed in the 2010 release but I’m not quite sure.)
• Dotfuscator – As far as I remember, this was another tool I remember having concurrency issues on the same build machine.
• Symbol Server Store Access – This is something new to me and I’m not intimately familiar with all of the details behind this limitation.  It looks like you can not use the symbol server publishing tools against the same symbol server storage location at the same time even on multiple machines.  (See example below.)
• Other Tools – I’m sure there are other build processes and tools we use that have limitations.  I’m sure many will be found out now that concurrent usage is more easily possible now.  Leave a comment below if you find any other examples and I’ll add them to this list.

Thankfully, the Team Build folks have provided us the ability to handle those specific scenarios where concurrent access isn’t supported as part of the build process.  That’s through the use of the Shared Resource Scope activity.  (Microsoft.TeamFoundation.Build.Workflow.Activities.SharedResourceScope)

Basically what it does is define a region of the build process that will only be allowed to be entered by one build across the entire Team Project Collection (even multiple build machines/agents) that share a matching resource name string.  It’s very similar to how we use the lock statement in C# or creating mutex objects.  (You might have to dust off those old computer science books from school.)

However, if you only want to limit the scope to a particular build server (instead of the entire Team Project Collection) then you can just put the build server machine name into the resource name string.  Don’t hardcode the machine name though and instead use one of the properties that are provided for you (in case the build doesn’t run on the same build machine every run because of the new agent pooling feature.)  Instead you could use an approach like this for the resource name expression:

          =String.Format(“{0}_{1}”,
BuildAgent.BuildServer, “AutomatedUITesting”)
        

Example in the Default Build Process Template in TFS 2010

Interestingly, there is an example usage of this activity and pattern available for us to look at in the default build process template file that’s available out of the box.  It’s usually located in version control here:  $/TeamProjectName/BuildProcessTemplates/DefaultTemplate.xaml.  Lower down in the default process, there is a section that attempt to publish the symbols to a symbol server storage location if you have specified it in your build definition properties.  My Assumption:  However, since only one build server can be publishing to a particular location at the same time, then a controlled scoped region is created based on the location property. (SourceAndSymbolServerSettings.SymbolStorePath)

That way you don’t have to worry about any build agent inside a Team Project Collection ever publishing to the same symbol server location at the same time.

Recently added:  It looks like this particular issue has already been discussed and that my assumption above is correct.  Adam blogs about it here.  Check it out.  How about that?

One more thing to note about symbol server publishing is the use of the SharedResourceScope activity in the build process template. The purpose is to make sure that concurrent instances of symstore.exe aren’t adding symbols at the same time, as the tool doesn’t support concurrent access to a symbol server share. SharedResourceScope uses the Team Foundation Server to control access to an arbitrarily named resource, in this case the share. That way, if multiple builds are trying to publish symbols at the same time, the requests are queued and only one will publish at a time, while the others wait (instead of fail due to file access errors or “step on each others’ toes”). PublishSymbols does not care about shared resource locks, but it is contained within the SharedResourceScope, so won’t be executed until the lock is appropriately acquired.

Other Properties Available for SharedResourceScope Activity

As you can see above there are a few other properties available for you to configure for this activity:

• MaxExecutionTime:  This is a TimeSpan that can be specified to limit the amount of time that a particular agent has control of the scope.  This is particularly useful for a resource scope that is going to be heavily used and can help you prevent a rogue build from eating up that resource indefinitely.  If the process inside the scope can’t complete before this time period has expired then an exception gets thrown.
• MaxWaitTime:  This is a TimeSpan that can be specified to limit the amount of time to wait for control of the scope.  The example above limits the amount of waiting to one hour and if it doesn’t reserve the scope within that time period an exception gets thrown.

Thanks to Aaron Hallberg for all of the background information and existence of this activity!

Ed Blankenship

Disclaimer:  I’m writing this at a time when only Beta 1 is available for Visual Studio Team System 2010 so the information may have changed by the time it has been released.  I have included links to the relevant MSDN articles which should remain valid after release time so just double-check.

This small little additional feature is actually one that I have been looking forward to for a long time.  In Visual Studio Team System and Team Foundation Server 2010, you will now be able to limit your test runs to specific test categories with a new command-line option on MSTest.exe and therefore in Team Build 2010 which calls MSTest.exe automatically for you.

Back in the day… You would need to create test lists (.VSMDI files) in VSTS 2005 and VSTS 2008 to basically “categorize” your automated unit tests by putting them into different lists.  One handy thing about them is that the lists could be hierarchical which helps out at build time.  When you wanted to run a specific subset of tests either locally using MSTest.exe or in Team Build, you would just specify the .VSMDI file to use and then the test list you wanted to run.  Not too bad, but it’s a pain to keep up with those test lists.  Serious pain.  However, the thing that I hated absolutely most about them is that you could only edit the .VSDMI files if you purchased Visual Studio Team Suite or the Tester Edition.  So that means that if you have just the VSTS Developer Edition then you are pretty much out of luck.  For most places that I have seen, it’s usually the developers maintaining those test list files not the testers.

For this reason I actually prefer and will be recommending the Test Container and Category approach going forward in 2010.  Test Containers are essentially files that contain tests in them.  For example, unit tests (and other compiled tests) are stored in .dll files and ordered tests are in .orderedtest files.  I like this approach.  In automated builds I just want to specify which files contain the tests that I want to run and then if I want to limit the test run to just a subset I can just list which categories to run. 

A great example of this is what I call the “BVT” category.  These are the tests that you have identified to be your “smoke” tests that make sure a build is okay.  If these tests fail then you’ve probably got a bad build.  (BVT = Build Verification Tests) So I would limit the test runs on any CI or even the new Gated Check-In builds to just those BVT tests.  Quick & dirty verification is really all you need for those builds leaving a more extensive automated test pass to happen during the nightly or weekly build.  If you’re not familiar with the new Gated Check-In feature in TFS 2010, check out Brian’s blog post or Patrick’s blog postfor more information.  It’s a killer feature.

This does rely on one thing though… each “developer” of an automated test needs to make sure they add the correct attribute(s) to their test methods.  You don’t have to keep up with maintaining the .VSDMI files any longer but you do have to make sure you mark each method appropriately.

You can even use test categories with the new types of automated tests available in 2010 like Coded UI Tests.  It doesn’t just have to be unit tests.

How to Specify a Category in an Automated Test

This part is pretty easy.  You just add as many TestCategory attributes to the test method as you need.  Here’s an example in C# using multiple test categories for a test method called DebitTest:

[TestCategory("Nightly"), TestCategory("Weekly"), TestCategory("Monthly"), TestMethod()] public
void DebitTest() { }

Alternately, you can select a test in the Test View tool window and then set the category by using the Properties tool window in Visual Studio and it will add the appropriate attributes to the methods for you.

How to Specify which Categories to Run in an Automated Build with Team Build 2010

Okay… this part is easy too. :)  Build definitions now have build properties that can be exposed to the end user in the Build Definition Details dialog or in the Queue Build dialog.  This is handy because you could by default not set a filter to run under normal circumstances (triggered or default manual builds) or you can change it when manually queuing a build if you want that build to run differently.  Either way it’s the same for setting the categories.  If you’re using the default build process workflow that is available out of the box, then just scroll down through the property list until you reach the Testing section which includes a build property called Test Category.  Leave it blank if you want to run all tests or specify the categories you’d like to limit it too:

According to the MSDN documentation for the Test Category switch, you can combine multiple categories in different combinations instead of just specifying one category.  Very handy – here’s some examples:

/category:group1 runs tests in the test category "group1".

/category:"group1&group2" runs tests that are in both test categories "group1" and "group2." Tests that are only in one of the specified test categories will not be run.

/category:"group1|group2" runs tests that are in test category "group1" or "group2". Tests that are in both test categories will also be run.

/category:"group1&!group2" runs tests from the test category "group1" that are not in the test category "group2." A test that is in both test category "group1" and "group2" will not be run.

What I’m not sure about is whether you can specify test categories when using the old Upgrade Build Workflow template .xaml file… I’ll check on that and then update the blog post.

It’s worth noting that if you are going to use the test category method to limit test runs, you must use test containers.

Limiting Test Runs Based on Test Priorities

If you noticed in the screenshot above from Team Build, you can also limit your test run to tests that are in a specific priority range.  How do you specify the range for your test methods?  You can use the Properties window when selecting a test in the Test View tool window or you can add the Priority attribute manually to the test method.  After that you just specify the range of priorities to use in the test run.

[TestCategory("Nightly"), TestCategory("Weekly"), TestCategory("Monthly")]
[TestMethod()] [Priority(1)] public
void DebitTest() { }

Additional Note:  It appears that the product team is actually encouraging people to move away from the old .VSDMI approach in favor of categories.  Check their note out:

Note

Test categories are recommended for use over the test lists functionality from earlier versions of Microsoft Visual Studio Team System Test, unless you have to create a check-in policy which requires a test list. For more information about check-in policies, see How to: Add Check-In Policies.

Take care and happy testing,

Ed Blankenship

Just wanted to take a few seconds to post the slide deck I’m using for my Real World TFS sessions.  I’ll post a link to the recording of the MVP TV session earlier today when it’s made available!

Ed Blankenship

Also really excited about doing my first ever MVP TV set up by the Microsoft MVP program.  Hope to see you there!  We have an extra thirty minutes at the end so be sure to bring your questions.

MVP TV: Real World TFS: Tips for a Successful Team System Implementation

Wednesday, July 15^th, 2009 | 9:00am – 10:30am (PDT, Redmond time) or 12:00pm – 1:30pm (EDT, New York City time)

Targeted: This Product Group Interaction is open to  all Developer MVPs in all Technical Expertise and  public audience.

So you’ve decided that Visual Studio Team System & Team Foundation Server is going to bring your organization added value (because it will :)) but what do you do now?  Please join Ed Blankenship as he covers the 2.5 years of successful implementation of VSTS and the experience of that journey at Infragistics, the world’s leading maker of software development tools.  The session intends to cover each phase of the implementation of all affected areas for a smooth adoption:  Version Control, Builds, Work Item Tracking, global deployment, moving multiple teams, training, automated testing, migration from legacy systems, and integration with other systems and TFS.  The goal will be to go through at a high-level of what it takes to make you successful by learning from the challenges and obstacles overcome.  We’ll also look in the future with VSTS 2010 and see how strategic planning will help make a successful adoption of the new features in the upcoming 2010 release.  The session is led by a Microsoft MVP (Team System) & Champ who has been in the trenches during the whole implementation.

Prerequisites:  A healthy attitude in learning from other peoples challenges and a strong desire to make real change within your organization!

About Ed Blankenship: Ed is a Microsoft MVP, Microsoft Certified Application Developer, and works as the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components. His expertise consists of Microsoft Visual Studio Team System and Team Foundation Server. He is also a technical evangelist for Rich Client applications (primarily Windows Forms & Windows Presentation Foundation.) He has been a technical editor for several Silverlight books, an article author, and has spoken at various user groups, events, and conferences.

PJ Forgione has invited you to attend an online meeting using Live Meeting.
Join the meeting. (Link: https://www.livemeeting.com/cc/mvp/join?id=NP5FQZ&role=attend&pw=A49410Y0D )
Audio Information
Computer Audio
To use computer audio, you need speakers and microphone, or a headset.
Telephone conferencing
Use the information below to connect:
Toll-free: +1 (866) 500-6738
Toll: +1 (203) 480-8000
Participant code: 5460396

Ed Blankenship

While I’m up in New Jersey working at the Infragistics headquarters office, I’m going to have the privilege of speaking at the New York City VSTS User Group on July 28, 2009 at 6:30 PM.  Come see me if you’re in the area!  Because of security concerns at the building, you do need to register ahead of time if you’re planning to attend.

Real World TFS: Tips for a Successful Team System Implementation

Description:
So you've decided that Visual Studio Team System & Team Foundation Server is going to bring your organization added value (because it will :)) but what do you do now? Please join Ed Blankenship as he covers the 2.5 years of successful implementation of VSTS and the experience of that journey at Infragistics, the world's leading maker of software development tools. The session intends to cover each phase of the implementation of all affected areas for a smooth adoption: Version Control, Builds, Work Item Tracking, global deployment, moving multiple teams, training, automated testing, migration from legacy systems, and integration with other systems and TFS. The goal will be to go through at a high-level of what it takes to make you successful by learning from the challenges and obstacles overcome. We'll also look in the future with VSTS 2010 and see how strategic planning will help make a successful adoption of the new features in the upcoming 2010 release. The session is led by a Microsoft MVP (Team System) & Champ who has been in the trenches during the whole implementation.

Presenter: Ed Blankenship

Bio:
Ed is a Microsoft MVP, Microsoft Certified Application Developer, and works as the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components. His expertise includes Microsoft Visual Studio Team System and Team Foundation Server. He is also a technical evangelist for Rich Client applications (primarily Windows Forms & Windows Presentation Foundation.) He has been a technical editor for several Silverlight books, an article author, and has spoken at various user groups, events, radio shows, and conferences.

Date/Time:  07-28-2009 6:30 - 8:00 PM

Location: Microsoft Offices in NYC at 1290 Avenue of Americas, 6th Floor

Click here to Register

Ed Blankenship

I’m up really early this morning.  I’m about to head to the airport to spend my Independence Day weekend in the Carolinas for some much needed beach vacation and visit with friends.  Thankfully, I didn’t miss Martin Woodward letting me know that the latest Radio TFS episode was made available just a few moments ago that includes my interview about our use of TFS and Visual Studio Team System at Infragistics.  It’s a longer episode than normal so it’s perfect if you’re going to be spending some time at the beach like me and listen to a fun talk.  We both really enjoyed chatting for this episode so we hope you enjoy it as well!

Using TFS with Ed Blankenship

In this episode we sit down and chat with Ed Blankenship about the use of Team Foundation Server at Infragistics. Ed has had some interesting challenges and experiences in running their TFS instance.  Additionally they have done some fairly advanced integration work which we discuss in detail.  This is a double-length show, so hopefully plenty of stuff to enjoy if you are sunning yourself on a beach somewhere.

Ed is the Release Engineering Manager at Infragistics, makers of the world's leading presentation layer tools and components.  He is also a Microsoft MVP in Visual Studio Team System.

     Play Now: Using TFS with Ed Blankenship

As the Release Engineering Manager, he leads the Release Engineering Department which is responsible for automated builds, creating product installers, packaging source code for customers, source configuration management/version control, metrics, release management, work item tracking, licensing enforcement, and development of internal productivity tools.  The department also is responsible for TFS Operations & Maintenance.

Ed has been a technical editor for the Wrox Silverlight 1.0, Silverlight 2 Developer's Guide, and Silverlight 2 Bible books, author of numerous articles, and has spoken at various user groups, events, and conferences.

Links from the show:

• Ed's Blog
• Microsoft Process Template
• Martin's Blog Post on Check-in Policies
• How to turn on Activity Logging with TFS 2005

As usual send any feedback to radiotfs@gmail.com.

Feel free to let me know if you have any questions based on the Radio TFS chat.  I’m more than happy to get them answered for you!

Take care,

Ed B.