I am involved in an ‘experiment’ of sorts here in the Developer Division at Microsoft, Mike Sampson and I have teamed up to see what the MSF Agile development process would like like on the Deployment Team. This serves as a data gathering mission for how we should structure SDE and SDET work here at Microsoft and is also a great opportunity to play around with Visual Studio Team Foundation Server.
I plan on blogging regularly about my experiences with MSF Agile and VS TFS, and today’s “Awesome feature of the week” is the Team Builds feature.
In Team Foundation Server, a project can be linked to Team Builds or custom builds which can be produced and tracked all within TFS. Other than storing basic configuration information, a team build also has two exciting enhancements: first, you can specify tests to be ran as part of the build process and second, you can mark the build with a given quality.
So for our project we have two builds types. A ‘daily build’ runs a minimal set of our automation and is checked out by test (me) semi-regularly to make sure it is OK, but for the most part those builds are left as “unexamined” status.
At the end of the week however is a more formal drop, which as part of the build process runs our entire battery of tests. Afterwards I set the build quality as necessary.
The benefit of this system is that nobody asks, “Where is the latest build?” Because all they have to do is click on the Team Build type and they know exactly where it is, when it was made, and its quality. Pretty neat if you ask me!