Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

December, 2006

Posts
  • Buck Hodges

    Brian Harry's explanation of Rosario

    • 1 Comments

    Brian's post What's in a Code Name? provides some explanation behind the Orcas and Rosario code names.  You won't hear the word "Rosario" normally, and here's a bit on why.

    What's in a Code Name?

    Mary Jo Foley is writing about one Microsoft code name per day on her blog.  I think it's pretty cool and there's a few code names I've never even heard of before.  She has written about a couple of Developer Division code names so I thought I'd add my own colorful commentary.

    ...

    So we get to Rosario.  Rosario is a resort on Orcas island.  It is a code name that the VSTS team has been using to describe our next version (after Orcas).  Actually when you see me talk in many forums about "the release after Orcas" what I really mean is Rosario but I don't use that term publicly - a bit more on that in a minute.  We created the Rosario code name to describe some work that we (VSTS) really want to get done and doesn't fit in the Orcas release.  In a sense Rosario is a place holder code name.  As Orcas unfolds and the rest of the division turns their attention to what is next for them too, we may see changes in what we currently believe our Rosario plan is.  For now we'll plow ahead with what we think we are doing :)

    ...

    Lastly and specifically, one of the reasons you don't hear us (and I think still won't) using the Rosario code name much is we don't want to take the focus off of Orcas.  Orcas isn't even in Beta yet.  It's a great release with tons of cool stuff.  Yes, we're doing even more cool stuff after Orcas and once Orcas gets a little closer we'll probably start to talk more openly about it.  But until then, we'd like to keep your focus and feedback on Orcas so we can make that the best release possible.

    tags: , , , , ,

  • Buck Hodges

    How to add your own message in the build report

    • 0 Comments

    If you've ever wanted to add your own message in the "Build Steps" section of the detailed build report, Aaron Hallberg provides a custom task to do it.

    Aaron, along with the rest of the team, had been focused on finishing up the continuous integration feature for Team Build.  I'm happy to say that we got it finished and checked into the main-line code this week.  It'll be in the next CTP that's released.  It's also in a Channel 9 interview that Brian Keller taped yesterday where Jim Lamb and I talk about Team Build as well as demonstrate the new features.  Brian recorded interviews with a number of TFS folks here in NC, which should be available in the near future.

    The Triumphant Return?

    In any case, during a conference call the other day, a Team Build user expressed a desire to easily insert build steps into a build from within a csproj file... In previous posts I have laid out custom tasks which, as part of their execution, insert build steps. In this post, I lay out a simpler custom task which inserts arbitrary text as a build step - think of it as a <Message> task in Team Build form.

    tags: , ,

  • Buck Hodges

    Visual Studio 2005 Service Pack 1 released

    • 2 Comments

    Visual Studio 2005 Service Pack 1 was released yesterday.  Here are the direct download links.

    · VSTS SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC&displaylang=en

    · TFS SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=A9AB638C-04D2-4AEE-8AE8-9F00DD454AB8&displaylang=en

    · Quiescing GDR (required for the TFS patch): http://www.microsoft.com/downloads/details.aspx?FamilyID=c18c756e-8f80-4987-b3bf-600068a9e3c4&DisplayLang=en

    Heath Stewart has a blog post on how to slipstream Visual Studio 2005 Service Pack 1.

    tags: , , , ,

  • Buck Hodges

    Third party add-in: Test Manager Add-In for Microsoft&reg; Visual Studio&reg; 2005 Team Edition for Software Developers

    • 0 Comments

    Many customers have expressed their disappointment with the fact that test lists (.vsmdi files) can only be created and managed in VSTS for Testers or VSTS Suite, leaving VSTS for Developers users in a bind.  There is now an add-in from Ekobit that solves this problem!  Check it out!

    Here's the announcement on Ognjen Bajic's blog.

    Test Manager Add-In

    Do you have lots of unit tests (or other automated tests, for that matter)? How do you organize them in lists? Using Visual Studio Team Suite? Nice, you’re covered. In Team Suite you can use the Test Manager window to easily build hierarchies and lists of tests.

    But what if you are just an ordinary developer using Visual Studio Team Edition for Software Developers? Test Manager window is not there to help you. A simple Test Window window with possibly endless list of tests is the best tool Visual Studio can offer. The only two Visual Studio Editions supporting Test Manager and management of tests are the all-encompassing Team Suite and the one specialized for testing: Team Edition for Software Testers. Are the developers really left in cold?

    Not any more! :-)

    As of today, Test Manager Add-In for Visual Studio Team Edition for Software Developers (what a mouthful) comes to rescue! Test Manager Add-In offers everything needed to successfully manage and execute tests and organize them in hierarchical lists in the developer’s own working environment. Being a VSIP package, Test Manager Add-In is seamlessly integrated in the Visual Studio environment and works flawlessly with other parts of the Visual Studio integrated testing framework.

    Read more about Test Manager Add-In here (http://www.ekobit.com/testmngr.aspx).

    Download the free 30-day trial of Test Manager Add-In from here (http://www.ekobit.com/download_testmngr.aspx)

    tags: , , , , ,

  • Buck Hodges

    Submit questions for the Channel 9 interviews of the NC TFS team

    • 0 Comments

    Brian Keller, technical evangelist for VSTS, is coming to the North Carolina office to interview Brian Harry and folks from each of the feature areas developed here (I'll be in the Team Build segment).

    Submit Your Questions for the Upcoming Channel 9 Interviews of the Team Foundation Server Team

    On Dec. 14 & 15 I will be filming more Visual Studio Team System Channel 9 interviews on-site with the Team Foundation Server team in Raleigh, North Carolina. I am pleased to announce that Brian Harry has graciously agreed to take some time on camera to talk about the roadmap for Team Foundation Server which he posted last week. I am also scheduling time with several of the other engineers on the team to go deep on areas such as the Migration Toolkit, the upcoming Power Tools, the Team Build enhancements, and some of the Administrative and Operations improvements being planned for Team Foundation Server.

    In preparation for these interviews I want to give everybody a chance to submit your own questions! I will use as many of your questions as possible during the interview. So send me your questions by December 13th, and if you want me to mention your name during the interview please be sure to let me know who you are, what you do, and where you are from. And remember, there's no such thing as a stupid question. So if you simply want to know what Brian ate for lunch the day of the interview, just let me know. (Though I'm sure you can come up with far better questions than my example. <g>)

    So, head over to Brian Keller's post and leave a comment with your question.

    tags: , , , ,

  • Buck Hodges

    More on the Orcas features for Team Build

    • 8 Comments

    Brian Harry posted a TFS roadmap.  I'd like to expand on the portion that describes the features specific to Team Build.  Keep in mind that these features can change before Orcas ships, so there are no guarantees that it will match what's described below.

    Build

    1. Support multi-threaded builds with the new MSBuild.
    2. Continuous Integration – There are many components to this, including build queuing and queue management, drop management (so that users can set policies for when builds should be automatically deleted), and build triggers that allows configuration of exactly how when CI builds should be triggered, for example – every checkin, rolling build (completion of one build starts the next), etc.
    3. Improved ability to specify what source, versions of source, and other build properties.
    4. Improved extensibility of the build targets – such as ability to easily execute targets before and after each solution/project is built.
    5. Improved ability to manage multiple build machines.
    6. Stop and delete builds from within VS.
    7. .NET Object model for programming against the build server.
    8. Simplified ability to specify what tests get run as part of a build.
    9. The ability to story build definitions anywhere in the version control hierarchy.

    There's a lot there.

    The first item refers to the feature in msbuild where it spawns multiple processes to build projects in parallel, for projects that don't depend on each other.

    Continuous integration is the flagship feature for Team Build in Orcas.  There's a build definition dialog that lets you specify all of the build "metadata," such as the name, workspace mappings, location of the tfsbuild.proj file, the build agent (aka build machine), and so on.  The workspace mappings for a build definition (called build type in v1) are stored in the database, so that we can efficiently determine which build definitions are affected by a particular check-in and thus need to be queued for building.  The dialog allows you to select one of your workspaces to be used as the "template" for the build workspace.

    Build agents are first-class objects in the system.  A build agent encapsulates a computer name, port number, description, build directory, and status (enabled, disabled, unreachable, or initializing).  Build agents can be added and removed as needed.  When a build agent becomes unreachable or unresponsive, the error message is stored with the agent and is displayed in the GUI to aid in determining what went awry.

    Every build goes into the queue for a build agent, and queued builds have priorities, can be postponed (paused), and removed from the queue.  CI builds are queued with a version that specifies which version of the sources should be built.

    Drop management is really about build management.  You can specify build retention policies for a particular build outcome (failed, stopped, partial success, successful), and the policy controls how many builds should be kept (none, all, or a particular number).  You can override the policy for a particular completed build and specify that it should be kept until it is deleted manually.

    With CI you get the ability to build each individual check-in, or you can choose to accumulate checkins over a period of time such that builds start no more often than the number of minutes that you specify.

    In items 3 and 4 we've really tried to address a lot of the feedback from users, including the MSDN forum.  There are a lot more extension points in the targets file.  You can have different targets executed before and after each project or solution, get separate log files for each project and solution, create workspaces spanning multiple team projects, specify additional msbuild switches when starting a build, experience better error reporting, and more.

    The tfsbuild.proj file can be located anywhere in the tree, and all of the paths in it can be relative to either local or server paths, allowing it to work well with branch and merge (i.e., there are no branch-specific paths in the proj file).

    Yes, you can stop and delete builds from inside Visual Studio.  You no longer have to fire up the command line to do that.

    With Orcas, Team Build gets an object model.  Version 1 shipped with only the wsdl.exe-generated proxies.

    The "simplified ability to specify ... tests" refers to the product version of the TestToolsTask enhancement I posted about earlier, which allows you to specify test "containers," such as assemblies, rather than having to use test lists (.vsmdi files).

    There's a lot more that we want to do in the future.  This is really just the beginning.

    tags: , , , , , ,

  • Buck Hodges

    TeamPrise 2.0

    • 0 Comments

    Congratulations to the TeamPrise team for shipping version 2.0!  Martin Woodward posts about it and includes screenshots.

    Teamprise Turns 2.0

    Tuesday marked the beginning of my second year with Teamprise and today I'm very happy to report that we have just released Teamprise 2.0.  To celebrate I thought I'd give you a quick run through of some of my favorite features.

    more...

    tags: , ,

Page 1 of 1 (7 items)