27 April 2007
TFS Exam 70-510 Goes Live w/Study Guide
26 April 2007
Answering: "When will bug 'xyz' be ready for testing?"
Have you ever been asked any of the following questions regarding work items: Is bug #123 ready for testing yet?, or When will I be able to test bug #456?, or What bugs are in the pipeline that will be ready for testing next?
If you're like me, you've probably answered the above questions at some point in the past something like: "Sure, it's been ready for testing for two days.", or "Bug #456 will be ready for testing after the next nightly build.", or "I don't know what bugs will be coming next, let me run some queries and get back to you."
Now, I'm a huge fan of Team Foundation Server but I hadn't stopped to take the time to put together a couple of relatively simple queries that would not only save myself and my fellow co-workers some time, but also make everyone's job just a little bit easier. Before I detail the two queries that eliminated the above questions, here's some details on our environments and automated builds.
Currently, we develop projects and push them through four environmental stages:
- Development: this is where all developers work on a daily basis - more-or-less isolated from the rest of the world.
- System Test: this is the environment that our testers perform their daily testing.
- Integrated Test ("Staging"): this is where we test out the integration points among multiple applications.
- Production: of course this is the environment in which our daily business runs.
Now, for each of our Team Foundation Server projects, we have three standard build types:
- Continuous Integration Build: this build type is automatically executed with each check in and deploys any binaries, files, etc. into the Development environment.
- System Test Build: this build type is executed nightly on a scheduled basis. All binaries, files, etc. are deployed to the System Test environment where our QA/Testers can "work it over" the following day.
- Integrated Test Build: this build type merely stages the various binaries, files, etc. to be pushed by the Integrated Test environment via CM processes.
So, back to the original goal of eliminating the original questions above. To do this, I created two queries named:
- Work Items Staged for Testing - this query, when ran, returns a list of all work items (e.g. Bugs) that have a State of "Resolved" and an "Integration Integration Build" (displayed as "Resolved in build" on the Work Item's Details tab) beginning with the text "Continuous Build" (the name of our CI build type). So, basically, this returns a list of all Work Items that have been associated with a changeset that has gone through the CI process, which means it has been deployed to the development environment and will be deployed to the System Test environment after the next nightly build.
- Work Items Ready for Testing - this query, when ran, returns a list of all work items that have a State of "Resolved" and an "Integration Build" that does not begin with "Continuous Integration Build" and is also not empty. I do not specifically check for a "System Test Build" in this query because I am assuming that any build type other than the CI build deploys the changes into an environment from which they can be tested.
With the recent acquisition of TeamPlain by Microsoft, we have deployed the TFS portal within our project teams giving our testers a nice web-based interface into TFS. Now, when they are curious about the state of existing work items, they can run the queries detailed above and get their answers immediately.
One caveat to all of this, if you decide to implement similar queries then you must ensure that your developers associate work items with their changesets when checking in source code (or other files).
Also, your build types must have the <UpdateWorkItems> element in your build scripts set to "true". This setting is what causes the "Integration Build" value to be updated to the latest build number associated with the work item.
Without the integration of TFS & Visual Studio, these types of queries would be a lot more difficult (if even possible) to build.
17 April 2007
71-510: TS: Visual Studio 2005 TFS Beta Exam Results Are In
As you may have noticed in other posts, the results for the 71-510 beta exam are starting to show up on participant transcripts (on the MCP member site). If you took the test a couple of months back then you may be able see your results by now. I checked mine today to find out that I passed the exam.
Now that the beta results are starting to appear, the "live" exam will probably be available soon. If you're planning on taking the exam, here are a couple of links to help get you started:
06 April 2007
Updated Team Foundation Server Roadmap for "Orcas"
The features marked as new include:
- TFS Best Practices Analyzer - A tool that can be run against your TFS server that will help diagnose configuration errors and tuning possibilities.
- VSTS Web Access - There's been much written about this already but the new Web Access product from devBiz will be released as a Power Tool in the next 60-90 days.
- Support for MOSS 2007.
- Official testing and support for more configurations - This includes clustering, mirroring, log shipping, Virtual machine deployment, and more.
- Scheduled builds - You can schedule builds to happen at specified times.
- Improved build agent communication - We replaced .NET binary remoting with WCF web services, simplifying some configuration and security aspects.
- Ability to run GUI tests as part of a build - Automated builds used to run tests in such a way as to prevent access to a GUI desktop.
- New checkin policy for broken CI builds - Preventing checkin while the CI build is broken.
- Offine improvements (Beta 2) - We've signficantly improved the experience going offline and integrated the tfpt online capability into the IDE for going back online.
- Extranet support for the TFS Proxy - allowing you to access a local TFS proxy with a different set of credentials than the TFS server.
- Command line help - You can now type "tf command /help" and get a console dump of the usage of that command. This is much more convenient than always being launched into the richer GUI hypertext help when you just want to remember what the options for a command are. You can still launch the GUI help by running "tf msdn". You can get a console dump of available commands by just typing "tf help".
- Source Control Explorer refresh improvements - This includes less redrawing and reloading but even more important it enables updates based on changes made in other instances of TeamExploror or the command line. That's right, if you checkout a file from the command line, any instances of TeamExplorer you have running on the same machine will automatically refresh.
- Query builder usability improvements - Drop down filtering based on current project, better MRU lists, column drag & drop, shift-click mouse based multi-column sorting, etc.
- Attachments improvements - Save button, drag & drop for adding an attachment, multi-select for attaching files.
- Tooltips on field names contain the field name used for querying.
- Server side support for deleting work items & work item types (Beta 2) - We didn't have time to do client UI support for it but we plan to release a Power Tool that will take advantage of the new server side feature.
The above list is only what has been flagged as "new" (some of which won't be available until beta 2). See Brian's original post for a complete list of all features.