I was flying on US Airways and was reading their January 2010 issue of their free magazine when I came across an article written by Robert Tuchman. It was titled The World Cup: How Sports Unites Us and states something that I’ve always believed: the round ball with the black spots on it is a great cultural barrier neutralizer. At Accentient, when we deliver classroom training to teams of software developers of mixed nationalities and cultures, we try to keep things as simple as possible, especially when the subject matter is as deep and dry as it is sometimes. Early on I made the decision to use the (soccer) World Cup as my point of reference in our samples, discussions, and activities. Everyone in the room, including the late-to-the-game Americans, understand the references to teams, matches, standings, and statistics. It has served us well. Go USA!
Microsoft has yet to provide us with some kind of utility to handle the importing, managing, versioning, and deploying of data along with our schema changes inside Visual Studio Team System 2008 database projects. For most of the teams I work with, their needs are simple: they just want the ability to store data (INSERT statements are fine) in scripts within their database projects. Ideally the project would be smart enough to know which version of data goes with which version of schema, but for now they’re able to live with handling that manually. Here’s one solution, albeit a manual one: 1. Create a database project.
2. Import database schema.
3. Launch SQL Server Management Studio (2008 version).
4. Right-click on the database and select Tasks > Generate Scripts.
5. Select the database and under Script Options deselect everything except for “Script Data”.  6. Click Next and select just the Tables you want (ideally just the smaller, static/lookup tables).  7. Click Next and specify the file to generate – something like LookupTableData.sql and let it rip.
8. You can now take that script and add it to your database project in a folder for data-related scripts.  Ideally you would link in the INSERT script(s) to your Post-Deployment script to automatically populate the data tables upon deployment. You can also use the option in the Generate Scripts dialog to give you one file per table, to maximize your versioning options. If you are already using Data Generation Plans, be careful to not overlap what they are already doing. For more information, be sure to read Barclay Hill’s Part 1 and Part 2 of a posting on how to manage data motion during your deployments.
Until the regular SDK documentation on MSDN is updated for Team Foundation Server 2010, you can find information at its official home on Code Gallery. You will find the samples for the Team Foundation Server SDK (samples are no longer included with the Visual Studio SDK), deep dive documentation, and links to shared source projects and other resources. This page is maintained by the TFS product team at Microsoft.
Somebody asked me a simple question the other day: “how do I export all of my work items at once”. I suspected they were looking to perform a backup, but it sounded like they might want to import into another system or just archive them in some readable way. I suggested Microsoft Excel, but it can only fetch work items from one team project at a time. So repetition, using a Macro or a human, would be required. Here’s an alternative we came up with … 1. Downloaded and installed Team Foundation Power Tools. 2. Picked one of the Team Projects, added a query, and removed the Team Project = @Project clause, so that it was completely empty:  3. Changed the Column Options, added the columns we wanted to export. For testing, we selected ID, Team Project, Work Item Type, and Title.  4. Ran the query and verified that it pulled the right work items and fields we wanted. 5. Saved the query (My query) and named it AllProjectWorkItems.  6. Dropped to the command prompt and executed the following commands: cd c:\Program Files\Microsoft Team Foundation Server 2008 Power Tools tfpt query "Calculator\My Queries\AllProjectWorkItems" /Server:vsts /format:xml > c:\AllWorkItems.xml 7. This command generated an XML file containing all of the fields from all work items from all projects. This satisfied their requirement.  At this point you can update the query adding more columns, until you have the superset of what you need for the export of all types from all projects. With a little finesse, the XML document could be migrated into Excel or another software application.
Out of the box, Microsoft has a Work Items check-in policy which requires you to select at least one work item when checking in your code in TFS 2008. If you install the Team Foundation Server Power Tools, you’ll get the Work Item Query check-in policy. This is nice because it allows you to specify a team query to which the work item associated with a check-in must belong. The example I give is that the team may want to spend the next couple of days on a “bug bash”, so you could use this policy to point to the “Active Bugs” query, etc. What’s missing is a policy that enforces you selecting exactly one work item during check-in. I believe this is crucial for maximum traceability: one changeset to one work item. This is a good habit to adopt as it increases the maintainability of the code, offering better get, branch, build, and merge options. Another way to put it: chatty check-ins (many, throughout the day) are preferred to chunky check-ins (one big one at 5pm). If only Microsoft had added a configuration page to either of the above policies, I wouldn’t have had to build this policy. Follow the P&P How-To guidance using the attached project to implement this policy. Attachments: SingleWorkItemPolicy.zip (19kb)
If you’re like me, then you don’t pay attention when you install a lot of software. Often times I just click Next > Next > Finish without reading the screens. For example, I guess I wasn’t paying attention to who the registered user was when I installed Visual Studio 2008 or Windows for that matter, because the splash screen shows this: 
Yes, it’s a registry setting and you can find/set it here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner 
Unfortunately, changing it didn’t do anything, until I learned the trick from John Robbins (Wintellect): After you change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RegisteredOwner, restart Windows and then run “DEVENV /setup” from an elevated PowerShell window. That will update the splash screen registry key.
Don’t trust the install guide that you find inside your Beta 2 download media. It’s an older version that was from last month. Instead, download the latest, beta 2 guide (TFSInstall-beta2-9192009.chm) here.
I’ve been doing a lot of work with the Database, er Development edition of VSTS 2008. Of course I’m running the GDR-R2 version which really changed the architecture of the database projects, as well as the process of building and deploying. Prior to the GDR, if you deployed a database project it would automatically create a Data Connection in the Server Explorer window. I liked this, because I would almost always follow-up a first time deployment with some data generation or unit testing, and it just made it easier to select the pre-defined connection from the dropdowns. It seems that the GDR erased this timesaver. For example, I just deployed a GDR-R2 database project according to these settings: 
And when I go to the Server Explorer window, I don’t see my VSTS\dev.AdventureWorks2009.dbo connection like I would have expected: 
Well it seems that this change was by design and it is configurable! According to Duke Kamstra, there’s a property in the database project (.dbproj) file that lets you control this behavior: <DeployToDatabaseAddToServerExplorer>False</DeployToDatabaseAddToServerExplorer> If you set the property to True, the connection will get added to the list which Server Explorer displays, and the behavior I enjoyed prior to GDR will return. For added coolness, if you always want this behavior you could modify the template(s) that are instantiate dbproj file(s) from: C:\Program Files\Microsoft Visual Studio [9.0 | 10.0]\VSTSDB\Extensions\SqlServer\ProjectItems\*\*.dbproj Duke also tells me that the same property exists in Visual Studio 2010.
I was at a client site last month where they have TFS2008SP1 installed and running on Windows Server 2008 SP1. Everything was working fine. We created several team projects. No problems.
I come back three weeks later and it wouldn’t create a team project. I kept getting the “Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server” error. According to the client, they hadn’t touched anything. So, I started with Ben Day’s blog post on the subject, but his fix didn’t work for me. I then checked all the service accounts, permissions, farm administrator group, database status, etc. – all the standard things, but no help.
Come to find out none of the SharePoint collection/sites would come up, let alone allow me to create new ones. The Admin site worked, but every other site gave the “Cannot complete this action. Please try again” wonderfully helpful error message. 
Windows event logs and SharePoint event logs were useless, but I did find a KB article talking about setting impersonation explicitly from code, so I decided to check the Authentication settings on the Default Web Site and sure enough it was Disabled. I changed it to Enabled, ran IISRESET for good measure, and voila!
I watch House enough to know that “everybody lies”. It’s a basic Houseism. That was the case here. The “we didn’t touch anything” statement turned out to be false.
I’ve been hearing about these type of government contracts more and more lately. I guess they’ve been around for years, but just maybe getting more popular in the circles I travel. IDIQ contracts provide for an indefinite quantity of supplies or services during a fixed period of time. They are frequently awarded by US Government agencies, including the GSA and the DOD. They are most often used for architect-engineering services, such as IT projects. As I work with government agencies, I find their waterfall approaches to project management and estimation to be frustrating. I hear a lot of “we do it because we’ve always done it that way” or “that’s just the way it is in government”. I continue to question this, especially when I see there are government agencies, especially federal, failure-prone ones who are learning to trust their (agile) vendors and IT service providers more and more. The IDIQ contract type is just such proof. It rocks. I did some searching and found that I wasn’t alone in this thinking. I found some articles on Alistair Cockburn’s site that mention IDIQ as part of a larger list of Agile contract approaches.
|