Anith Gopal

The TechReady event is an internal Microsoft event, so I cannot cover any of the event content.

We have a new wave of new Visual Studio ALM Rangers joining us, many of whom I hope will soon appear on the Rangers Index. When you join a new organization it is often daunting to find your feet while plummeting through thick thunderstorms and expecting the ground to appear at any second (if you have the tendency to jump out of planes), or ascending in heavy seas, through zig-zagging schools of fish and expecting a metal object (ship) or cave overhang to appear any second (if you are a deep sea diver). To cut a long story short, here are the “few” (7) steps you should follow when joining the Visual Studio ALM Rangers family: Introduce yourself on the Rangers Index … it is always great to match a face to a name and understand what make’s you tick Explore the Rangers portal , which is accessible to all Rangers, selected Visual Studio ALM MVPs and others

I have been getting a number of the same questions from the community and it is probably time to start a frequently asked questions blog series. What is the genetic makeup of a Ranger?

In Requirements Management for Ranger Projects … Epics, Team and Personas we mentioned the Rangers requirements management and the concept of Epics, also referred to as Experience. Here is the list of Epics from the Rangers Build Customization Guide project: For those that are squinting at the above image, here is a more readable list: Epic – Practical guidance and tooling to simplify the Team Build 2010 "Build" customizations Epic – Practical guidance to utilize Team Build process templates to automate build and non-build scenarios in Microsoft environments Epic – Practical guidance that allows utilization of Team Build process templates to automate build and non-build scenarios in non-Microsoft environments Epic – Practical guidance to enable simple and flexible flexible deployment of applications and their data stores Epic – Practical guidance for Activities to empower developers and build engineers Epic – Quality hands-on-labs that complement the guidance and effectively guide the user through the features Epic – Visualisation of the guidance using quick reference posters Do these Epics make sense? Do these Epics summarise the killer features of the project?

Grant C. recently sent us this question: “ I saw mention in the log of a TfsMigrationTool.ReflectedWorkItemId field but couldn’t find any docs / discussion about it.  I added it to my target WIT and also added my own TfsMigrationTool.SourceProject field as you can see in the config, but I’m curious if there are any other TfsMigrationTool.x fields the tool automatically sets. ” Great question, which allows us to introduce an originally internal Pioneer dog fooding feature, but one that could be invaluable to users of the TFS Integration Platform in WIT migration and/or synchronization scenarios.

Late last year we started the Visual Studio 2010 Architecture Guidance project … probably the worst time as December is a very inactive month with everyone enjoying a well deserved break and January  being a very active month to re-start initiatives, thus having little time and bandwidth for these kind of projects. Nevertheless the team has ensured that the guidance project is picking up momentum and recently released a DRAFT of the core scenarios to the Rangers for comment and are hard at work on a BETA release for the core scenarios and a DRAFT release for the extensibility and Hands-on-lab (HOL) scenarios.

Two kind-of questions recently bubbled up on the radar: Should we manually copy (migrate) files from source to target, to reduce the work that the TFS Integration Platform needs to do? In other words, does it help to be pro-active? No, because this manual action will introduce a “VC content conflict type” for every file that was migrated.

Thanks to everyone who attended our TFS Migration Tools TR9 re-run and a special thanks to Bill Essary and his team for supporting the VSTS Rangers “again”.  Apart from me running on my server after re-installing my laptop with Win7 over the weekend and an “important update install and imminent restart” warning message on the server just before the start of the session, the re-run went fairly well.

We have been working to create a home for the VSTS Rangers and their projects, to recognize the phenomenal contributions made by Team System experts and to better understand the interest in our VSTS Rangers projects. Thanks to Sharon , we now have our very own site Please check out http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx which is the first iteration of our new VSTS Rangers home page and associated Solutions and Projects page

Question: “I recognise the need to FI from MAIN to each DEV/CR branch on a regular basis, is there a way to automate this to run on check-in or every night perhanps? I’ve looked into this and keep reading about CI – but I can’t find any practical demonstrations of how this might be achieved.” My Response: Even if it was an easy thing to do (and I don’t think it would be) I don’t think it is practical to automate the forward integrations from MAIN to the DEVELOPMENT branches

Question from TFS Branching Guide 2.0 on Codeplex: “I am creating a new branch for each ‘Change Request’ that comes from the client – I love the idea of isolating the code this way. Do I have to create a new build definition for each, or am I missing something really straight forward? It seems like overkill for the smaller changes, but I want to keep a consistent set of rules – so if one change request gets a branch then so do all of them.” My Response: I think it may be overkill to isolate each customer change request into a separate branch.

The Virtualizing VSTS 2010 project is well under way and apart from working on virtualisation guidance around TFS and VSTS, we are also automating the creation and configuration of the VSTS Rangers base image. We are investigating a number of automation solutions, both internal and public solutions, as well as creating a pile of PowerShell scripts to automate the tweaking and customisation of the environment. Keep an eye on Robert’s blog , where he will most likely share a few PowerShell and general scripting nuggets while we are getting to grips with the automation challenge