Mingle Portal Page - Visual Studio 2010

With Visual Studio 2010 you can set a portal page link for any TFS Team Project. When using Mingle I set my portal to be my personal Mingle card wall, making it very easy for me to jump to the wall and saving clicks and keystrokes.

To do this:

- Right click on a team project node in Team Explorer

- Choose Team Project Settings -> Portal Settings

- Past in the link

Mine looks like this:

Card Walls for Organizing Your Work

ThoughtWorks Mingle makes it trivially easy to organize your personal work using 2-D card walls. We introduced them specifically to handle SCRUM projects. Yet they are flexible enough to do lots more. Here’s my personal “to do” list organized by project (rows) and timing (columns). Individual work items are in the cells and color-coded by type (story, task, etc.). It took me less than a minute to produce this. (Apologies for smudging the details, but my employer gets funny about disclosing proprietary information. Smile.)

Bought

This blog has not delved into politics, but this needs to be said:

Visit msnbc.com for breaking news, world news, and news about the economy

Sun Java on Ubuntu 11

Took some digging, but this finally worked.

sudo add-apt-repository “deb http://archive.canonical.com/ lucid partner”
sudo apt-get update
apt-get install sun-java6-jre sun-java6-plugin

Visual Studio vNext and Next Gen MSFT ALM

Microsoft presented a bit about their vision for ALM and the next generation of Visual Studio at Tech Ed last month. As usual with these sorts of announcements and white papers the signal to noise ratio of quite low. I'll help with a synopsis for folks who don't want to read the 32-page PDF.  First an editorial comment.
vNext doubles-down on the theme of Microsoft's development environment - automation. Their vision is a world where tools and process are effectively one and the same. They see their mission as providing amazing amounts of automation of routine tasks through the use of tools - their tools. In the Microsoft development ecosystem life is "easy". Microsoft provides you with all the tools you "need". In the process you may be blind to a world of thinking and building software that goes on around you.
 
Resource capacity visualization is nice.




Interactive drag-and-drop Task Board, which looks quite familiar.



Integrated MS Project Server (this is a feature add-on in VS 2010). This is a very cool feature, especially for enterprise resource planning spanning multiple projects. We can also do it with Mingle with a bit of code.



There's something called StoryBoard Assistant, that integrates into PowerPoint. They claim it facilitates better inbuilt graphical design tools, ability to embed other content, ability to create lightweight animations, etc. Personally I prefer things like SketchFlow in Expression Blend, which is a more "design UX in code" tool for WPF.



They've integrated e-mail for collecting stakeholder feedback. Presumably this was done so that it uses the default e-mail provider configured on the Windows client PC rather than being limited to Outlook.  This feature doesn't impress me much without seeing it since my personal bias is that demos are a much more effective feedback collection platform. If viewers are remote then one has tools like Skype, Webex, GoToMeeting and Live Meeting. One nice thing about this is they claim it's integrated into the web browsing environment so that it's easy to create feedback directly from a web page.



Unit testing in vNext is asynchronous to you can code and test at the same time. Sounds iffy to me. Do I really want my in-flight code being constantly tested? I know I want my checked-in code immediately tested using a GO pipeline. I do like the UI treatment of test results here very much.



Integrated code review looks spiffy. (TFS has facilitated code sharing for review using a feature they call "shelf sets" for years. It's one of my favorite features. A shelf set is code on the TFS server that has a name so it can be shared, but it's not checked in.)



They also claim to have added production testing scenarios to facilitate close communication between development and operations.

Moving Projects: Mingle vs. TFS

There is no contest. This morning I needed to create a new Mingle project on a server to which I do not have administrative access. It is easy to set up a local Mingle system on Windows, create the project, set up work-flow and other things I need and go to work. Exporting this project later and giving it to an admin on the other server to import takes about five minutes. Try doing this with TFS. Where are the export/import commands? Oh, there is a utility for this that is not included with TFS, complicated and cannot be used in five minutes.

Looking At TFS 2010 Build

I have been digging into Team Foundation Server 2010’s (TFS) build system with a particular eye on how it handles continuous integration (CI). Martin Fowler describes it this way:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

First we need to consider build automation in TFS generally. Then we can look at how it handles CI well (or not).

TFS 2005 does not handle automated builds well without a considerable amount of of trial and error to get a stable build configuration. I’d describe it barely usable. Things get better with TFS 2008, but time and patience configuring builds remains too much of a virtue.

The biggest issue in my view is the way-too-heavyweight role of the Team Project in the build process. TFS wants to pull the entire source tree for a Team Project to build anything. Having a source tree with several products it’s not unusual for me to put my team to work on a vertical slice of the tree. In a CI world I want to continuously integrate just Product A, I don’t really want to pull Products B and C to do that. So that’s an issue.

Second, I want to string together chunks of work in a build process like build, unit tests, integration tests, UI tests, stress tests and deployment. Doing this with TFS 2005 is a nightmare. It is better but still tedious with 2008. So I am excited to see if some of these issues are mitigated or eliminated in TFS 2010.

Let me point out that I got to that point with my source tree because I inherited a bunch of legacy stuff developed over six or seven years under a different source control system. Rarely are we blessed with the time (and energy) to redecorate a huge source tree when we decide to migrate to something like TFS to take advantage of work item tracking and better reporting, so I did not. If I had started from scratch with TFS maybe I’d have made different choices for how to set up Team Projects.

Enough history.

My intent with this post is to begin with a walk-through of TFS 2010 Build. I’ll come back and elaborate a bit if it makes sense. As to continuous integration TFS 2010 provides a build option with that name. The build process editor provides hooks for including build, testing and deployment. I have not taken TFS 2010 Build through an elaborate implementation yet to know whether it is as flexible as other systems like ThoughtWorks Go that have a rich model for breaking builds into stages and jobs.

TFS 2010 introduces an Administration Console that consolidates what heretofore was a conundrum of command line tools and Visual Studio. 

Here is a video that runs through build service configuration.

To set up the build system you first configure the build service. An important note about the account you use as credentials for the service is that this account needs write access to the “drop location” for build results in the file system. More on this later. Each Team Project Collection requires a separate build service. If you want to configure the service to run under a special account, you may. Historically it has been common to use a special TFSBUILD account.

 

Next, we configure a controller for this build service.

And one or more agents.

A configured build system looks like this:

We have our build infrastructure. Now, we’ll define a build process. This is done with Visual Studio starting from Team Explorer. Right-click on Build Definitions and indicate you want to make a new Build Definition. Tailspin Toys is my Team Project.

  

An editor opens and we give our Build Definition a name.

 

What triggers this build?

Pick a controller and a staging location for build results. The staging location must be writable by the account you configured with the build service. In this case my builds are going to a Drops folder on Frodo.

Pick a process template and fill in the process details. Here I am saying “build the Tailspin Toys solution with the Debug build option for Any CPU.” I am not specifying any tests to include in the process, but I could.

You can trigger a build manually.

There is a nice build manager UI inside Visual Studio:

Build results are quite nice providing a summary of issues wit the build if any and test results. You can register for alerts when there are build problems.