I'm basically an End User

Sorry for my lack of blogging lately. Basically, I've turned into an end user of TFS. How far the mighty falls. At one time I was the first person to bring TFS into a company of 35,000 people and administer the only TFS instance. My calendar was filled with demonstrations to both Directors and Vice Presidents. Now we have five or six implementations and I'm back to being a simple grunt. Which to be honest is probably where I belong.

While I don't do much TFS administration anymore (at least right now), I do offer my expertise. Like just yesterday a "Scrum Leader" asked the person administering TFS how hard it would be to not default the Current User to the Assigned To for our Bug Work Item. I gave a nod of encouragement indicating it would be a simple change.

We have ordered new hardware for my current group's instance though and I'm sure I'll get involved as we lay out the topology and do the migration. In the mean time, I'll just set back and enjoy TFS as an end user while I work on our deployment strategy.

TFS Statistics Query

A while back Brian posted on the SQL commands he uses to pull the Dogfood statistics. I seem to always lose this posting so I thought to write it down so I can quickly look it up on my blog.

I used most of them this morning on our TFS 2008 server and all the ones I took worked just fine. My "Scrum Master" (and yes I do bow before him), wants our numbers pulled every iteration which for us is two weeks.

Compared to my old group, we've got some pretty small numbers. For example, my old group had close to 10,000 changesets while this group only has just short of 800. But even though the numbers are small, I enjoy looking at them.

Anyway, if you need the queries to pull your own numbers, which I think you should, see Brian's post. Enjoy!

Web Service Versioning

On my new project team here is a lot of discussion around supporting multiple versions of our applications (which are most likely going to be a collection of web services). This affects me as I'm responsible for deployment of these applications. This got me thinking, how does TFS do versioning for their web services? TFS 2008 supports Team Explorer 2005 and 2008 so they had to have the same discussion we're having now.

As it turns out, it looks like they support multiple versions within the TFS 2008 code base by simply organizing the versions in a folder hierarchy. It looks very well organized and something that would be easy to deploy! Let me explain what I see.

Underneath %Program Files%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\Build I find both v1.0 and v2.0 folders. My assumption is that the TFS development team decided to put all new 2008 functionality in the v2.0 folder for each web service. In this example I just show "Build" but you can see similar things in "Services" as well. I'm guessing when the next release comes out, we'll see v3.0.

I'm the type of person who has really never created anything original. Well that's not 100% true as the book I'm writing is not simply copied from other fiction thriller writers. However, the fundamentals are based on the same story structure and writing format that most all novel writers use. I just simply follow the rules. Back to TFS though. I brought up the web services versioning I saw TFS use to our architects and from what it sounds like, they are going in a slightly different direction.

What we "plan" (plan is used loosely as they are constantly changing things) on doing is hosting each "version" under a separate IIS 7.0 site. Something like this I guess.

IIS
/AppPool1.0
    /WebServiceSite1.0
        /mycode
/AppPool2.0
    /WebServiceSite2.0
        /mycode

My understanding is, this will put each "version" in a separate worker process. The approach TFS took would not.

Personally I think the way TFS does web service versioning is better. That is, simply versioning the web services within a single deployment (i.e. site under IIS). But given we're selling/supporting different types of software (ours is hosted internally and we have full control over deploying it) I can see an argument for supporting multiple version as separate deployments under IIS.

Now this all comes with my standard caveat that I often misunderstand very technical details. I'm sure there is a number of white papers and studies done on web service versioning that trump any opinion I have. This is simply an observation of how I see TFS is doing some kind of versioning.

Sorting data in Reporting Services

Most things come hard for me. Whether it's been work, school or play, nothing has come easy.

So it should be of no surprise, I had a hell of a time trying to figure out how to sort our custom TFS build report. It honestly took me about four hours to figure out all you needed to do is set a Sorting Expression on the report's table when in layout mode. Here is a good article that explains it in detail.

I was trying to modify the MDX query, which is nearly impossible, by using an ORDER function. That was getting me no where as I could not get the syntax figured out. So after lunch I decided to do a bit of research and fell into the TechNet article. And about five seconds later, I found my answer.

If you need to do some sorting, check this article out.

Team Build hangs when using Pstools and the Exec task

In my new position they have given me deployment. Basically after the build and unit tests are run, they want the code deployed to the servers. We're running under IIS 7 so I've decided to write the deployment logic using AppCmd from the IIS 7 team. It looks like a very nice tool!

To execute the series of AppCmd commands (actually we've grouped them into a batch file that we call) we're using yet another Microsoft technology called Pstools. In this suite of tools there is psexec which allows you to execute remote commands. After we got past some odd domain --> workgroup permission errors, it works pretty well. The command we use is something like this "c:\tools\pstools\psexec /accepteula \\server cmd.exe /c c:\deploy\install.bat 0.0.25"

Back in our TFSBuild.proj file we're using the Exec task to execute this. Unfortunately the Exec task hangs. "Gonzobent" has submitted a wonderful write-up on this to Connect. I added my two cents in as well.

To get around this (as we need to so our deployment efforts can continue) we put the "non-interactive" switch (i.e. -d) on the psexec command. So now the command looks like this "c:\tools\pstools\psexec -d /accepteula \\server cmd.exe /c c:\deploy\install.bat 0.0.25". This is not ideal as we don't get any output back in the Team Build log file to see if the deployment works or not. We just assume it does - since I wrote it ;)

As I put in my comments on Connect, I think psexec is sending back MSBuild information it's not expecting. We ran into this a few years ago when we wrote a homegrown build system which had a Java application as it's Built Client. When a user ran a Ant script that failed, the system would just hang. There is a good article here that examples how we fixed it. We basically thread reading the output and error.

If anyone has any other work around ideas, please let us know.

Be careful with consultants

This goes for all software, but being I've been working with TFS for the past year, I thought it would be good to mention it on this blog.

In my last group, we implemented TFS by ourselves. That is, we did all the setup, migrations, training and ongoing support. We decided this was the best approach since the team was very technical and motivated to tackle a new configuration management tool. And for the most part, we were successful.

My new group took a different approach (before I got here) and hired out most of the TFS work. Everything from setup to customization has been done with the consultants taking the initial lead. We've been bumping heads a bit this past week because I take a slightly different view on how to implement a new product than they do. I think they have sold my new group on too many customizations.

I was a consultant for two years back in the early 2000s so I know a bit about the business. A consultant's number one goal is to stay billable. Meaning if you, as the customer, keep nodding your head, they will continue to do what you say and keep billing. If you're a consultant and reading this, don't get all bent out of shape. You are very necessary and we can't live without you, but there are times when a good consultant needs to help the customer say "no" to themselves.

We as customers get a bit too excited about all the possibilities TFS has, and forget that at the end of the day, everything costs money So when you say "hey we'd like to have check in policies for this and that", everything can be done, but it will cost you. And don't forget about the on-going maintenance costs.

So here is my suggestion. Start with the basics. That is, try to take what TFS has out of the box, then slowly start making the needed modifications with a well balanced team of consultants (if you need them) and full time employees. You'll be better off in the end.

Safari

I'll have to make this quick as my son is starting to toss up his sweet potatoes. We've had a number of "business" folks who want to use Safari for TSWA. They have had some connection issues that look similar to what happens when you don't have your proxy settings configured correctly in Firefox. That is, you continually get the authentication prompt while a portion of the screen renders in the back.

We've read about a number of proxy server and/or Windows Authentication issues with Safari. While I can't say that is the primary issue, we've directed the users to Firefox as that works just fine after the proxy connection is configured correctly.

eScrum instead of CMMI

It's been an interesting day in my new group. My former organization used the TFS CMMI templates. Our group wide CMMI efforts are pretty much dissolved, but TFS and the templates are still in use.

The new group is using something called "eSrum" and an Agile development mythology. From the looks of it, it's been around a while though I've never looked at them before. I thought Scrum and Agile were two different things, but from what I've found so far, people around here use the terms interchangeably.

They have an existing TFS system setup in their DEV environment. They were having some issues with creating "Build" reports as the eScrum templates don't include one. So I pumped out a few pretty quick referring back to Buck's posting here when needed. If you have not checked this out, you should. It's very helpful if you need to get up to speed with Reports quickly.

We also upgraded their TSWA from 2005 to 2008. I'm not sure why they were running 2005 as we're running 2008 for everything else. The upgrade was very smooth. It only took about 10 minutes after we got started.

Overall they have things pretty well setup in their TFS 2008 DEV environment. They do plan on scaling out to a full TFS deployment (i.e. primary/standby app servers with clustered data tiers), which we'll have to tackle when that times come.

Slight change in my role

If you're a regular reader of my daily Thoughts blog, you'll notice that I'm changing groups starting Monday. Oddly enough, the first assignment in my new group is to get TFS up and running for them.

The new group is starting off with TFS 2008 so I won't get to experience the 2005 to 2008 upgrade. However, given I'm just a floor away, I'm sure my old group will ask for some help when the time comes.

Given I'm heading to a new group, my postings may change slightly. I'll still be supporting Teamprise users, but over half the group uses Team Explorer so that may sway my subject matter a bit. I'm also taking on some more responsibility (with very little more pay). In addition to leading up the TFS adoption, which includes Work Item Tracking, Reporting, Documents, Team Build, and Source Control features (including branching and code-line policy), I'm responsible for deployment strategy. That is, how in the heck we're going to blow out the build results to large server farms. Daunting to say the least.

I hope you'll keep reading as I still plan on posting what has become simply a brain dump on our company's adoption of TFS.