Occasionally I'm asked about the business value of VSTS and TFS. I think it's pretty obvious, but I guess others need more convincing than just my word.
I've pulled together some links below that will help with this.
I was honored to learn that I had achieved the Bronze, Silver, and Gold awards for 2006. 
Thanks to all of you who read my blog, attend my classes, and generally listen to me ramble on about Microsoft's tools and technology. Without you I wouldn't have these giant coins to carry around! 
Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the latest Community Technology Preview (CTP).
Join the chat on Wednesday, February 7th, 2007 from 10:00am - 11:00am Pacific Time. 
As many of you may know, Dr. Jim Gray (Microsoft Researcher and Turing award recipient) went missing a week ago, on his sailboat Tenacious off the coast of San Francisco. I've had the pleasure, on several occasions, of speaking with Jim and learning more about his research. If we cannot find him, it will be a huge loss.
 |
The search for Tenacious (and Jim) is underway, in a big way. Many news agencies are calling it the largest private search for a missing person ever. This blog is aggregating all of the latest information.
Best of all, YOU CAN HELP!
Visit Amazon's Mechanical Turk site dedicated to finding Jim, and help by searching new/updated high resolution satellite imagery. All of the instructions are provided, you just need to donate some time. | 
Richard Waymire has publishes his long-anticipated whitepaper on permissions, security objects, and other security concerns centered around using the Database Professionals edition. 
Over the years, we've had a few clients automate their build process by using Final Builder by VSoft Technologies. Much like Team (Foundation) Build, Final Builder is a powerful build & release management tool. Unlike Team Build, Final Builder has a slick UI allowing a build master to quickly design the builds.
Last summer, a new Final Builder version (4.2) was release which included more support for MSBuild and Team Build tasks. With that version, and following the guidance in this article, you can get the two products working together! 
Wow! As I was downloading a file from MSDN that requires Genuine Windows, I was prompted to download the required tool. What was interesting was the prompt! They noticed I was using Firefox and even showed me Firefox screenshots for how to install the Genuine Windows tool!
Bottom line up front: Create a 'root' branch directly under the source control branch associated with a new Team Project.I see this all the time... Someone creates a new source control branch in TFS and starts creating solutions underneath the default project branch. In other words, they end up with this: $/ProjectName /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 Now, the difficult comes when the shop needs to create a second version of the application. Code branches directly under the root (i.e., $/ProjectName) can only be created when a new Team Project is created. If, in the above example, SolutionName1 and SolutionName2 both belong to the current version of the application, then creating a new version of the application will require either the creation of a new team project (with a branch from the $/ProjectName), or a wildly unweildly structure where each solution is branched, resulting in something like: $/ProjectName /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 /SolutionName1_v2 /ProjectName1 /ProjectName2 /SolutionName2_v2 /ProjectName3 /ProjectName4 A MUCH cleaner approach is so simple, yet requires a bit of forethought. Immediately after creating the Team Project, simply go in an create a new directory called 'root' (or 'edge' or whatever you'd like). You can then create a full branch of the V1 off the application by simply branching 'root'. This allows This resulting in the following structure, even after creating a v2 of the project. $/ProjectName /root <-- Create this branch! /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 /ProjectName_v2 <-- This is the branch of 'root' /SolutionName1 /ProjectName1 /ProjectName2 /SolutionName2 /ProjectName3 /ProjectName4 Now, whether you should have your projects under your solution directories... that's for another post...
How many build scripts do you need? There seems to be some massive confusion around TFS Build Scripts, namely, how many a single project needs. If your answer is one, you too have a misunderstanding!  In my experience, one build script is not nearly enough, in fact, I encourage several. Here's the why and how. Why: Visual Studio Team System (VSTS) and Team Foundation Server (TFS) is absolutely brilliant at tracking information related to a series of builds. That information is archived, analyzed and reported in a very useful fashion. BUT, it it reported by the NAME of the build. Thus, if you only have one build type, you can only have one set of reports! And that's no good! You need more. The primary reason for having more than one build type is to get good, easily understandable, accurate metrics.
- First, you need a build script for your continuous integration builds. This script runs every time someone checks in code (with certain restrictions). You likely won't want an aggregate report on these builds, except for rare cases -- there are just too many of them. This build is optional. I'm a fan of CI, but if it's a bridge too far, don't worry. The critical build is the nightly build...
- A TFS Build for your daily / nightly builds. This build runs every night at a set time. This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc. This is one of the most valuable builds, since its reporting is clearly segmented by time -- one build per day. This allows a team to see what is being accomplished on a day to day basis.
- A TFS Build for weekly builds. This runs every weekend. Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week. This allows you to see aggregate changes over a chunkier time sequence, namely weeks.
- An end-of-iteration build. I've found you don't need to go any longer than weeks this for most projects, as far as reporting is concerned. However, you may choose to create a build that runs at the end of every iteration. This gives you metrics on what was accomplished during the entire iteration.
- An on-demand build. This one is used for folks who just need to trigger a build whenever. Unless it's necessary or useful, you may choose to have this build not report anything back to the data warehouse.
How: It's easy! The reason for all these builds was stricktly for the reporting. That means that each of these builds is likely going to be nearly identical! So, all you need to do is create the first build (the hard part), and copy it several times, giving it a different name each time. That's all there is to it! So, go forth and replicate those builds!
|
Copyright © 2010 Richard Hundhausen. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|