Friday, September 19, 2008

"I'm a PC"...Come Again?

So I'm over at the local Microsoft office this morning for a meeting. I get there a little early to chat with my peeps and everyone keeps saying, "I'm a PC". Huh? Is this some new addition to the mountain of acronyms out of Redmond? Crap. I need wireless. Save me Google. Even the admin (whom I've befriended over the years...) is busting this out along with a sly, knowing smile. (Me returning the smile with a forced gesture likely resembling The Joker in Dark Knight). "Oh, how lovely. My 1-year-old threw up on me yesterday", was the response brewing in my head.

As this scenario keeps repeating itself, that old I-forgot-to-wear-pants-today-but-don't-realize-it nightmare sets in and I'm all freaked out. I have this deep-seated fear of calling someone by the wrong name (I'm terrible with names...sorry, I really do care about you) and I'm getting that clammy, can't-believe-I-just-called-Chuck-the-name-Ralph feeling of idiocy.

Finally, someone throws us a bone and identifies the elephant in the room (much to my relief) as Microsoft's new marketing campaign: "I'm a PC". Ohhhhh. It's actually very well done.

It's the first message from Redmond I can remember that, well, doesn't suck. ;-) I also found it impressive *every* Microsoft employee was in on it and behind the campaign. Good show. Enjoy.

Wednesday, September 17, 2008

SQL Server 2008 Express Installation Prerequisites

Attempting to install SQL Server 2008 Express recently, I kept receiving "...must install Microsoft .Net Framework 2.0 SP2". Huh? There was no SP2, AFAIK. Turns out there was but it's only wrapped into the .Net 3.5 SP1 redistributable. Leveraging this helpful MSDN forums post, I installed the following and successfully brought SQL Server 2008 Express up on a Win2k3 SP1 box.
Why does everything need to be so damn complicated?

Sunday, September 14, 2008

Virtual TFS User Group

It's a rough time (9PM EST) but some of the TFS heavyweights created a Virtual TFS User Group. Your local ALM group (COALMG) clearly is superior in community and value, however. ;-)

Sunday, September 07, 2008

Spirit of Columbus Half Marathon

Last Sunday, I completed the Spirit of Columbus Half Marathon. I beat my goal (under 2 hours) but the last 4 miles were killer. It showed. Training offered for an enjoyable summer of exercise but I'm hanging up the running shoes for a while...need to work on strength, flexibility, and balance.

Saturday, September 06, 2008

HOWTO: TFS: Can I Prohibit Merging?

Recently a client inquired if it were possible within the Team Foundation Server (TFS) Source Control authorization capabilities to prohibit merging. Having a long week, I brainlessly looked at the authorization options within Source Control Explorer (right-mouse Properties >> Security tab):

image

Nothing there. Then I knocked my forehead and realized one would configure this authorization as part of the branching mechanism. Duh. Merging is a client-side activity. If you can access the TFS server, you can merge. However, committing changes to server source repository requires Check In authorization.

My personal preference is to empower and entrust developers with a fair amount of responsibility. Thus, I like to enable merging into the integration branch for developers. However, this client wanted to restrict developers from merging and reserve this responsibility for accounts belonging to a TFS group (created by default) named "Project Administrators". These are folks playing, for example, the team lead role. Our developers have been added to another TFS group (also created by default) named "Contributors".

Let's assume we're leveraging a simple: Development >> Main >> Production branching mechanism within source control. The Development branch is somewhat wild-wild-west in that you want to impose few impediments to check-ins. Frequency of check-ins usually leads to higher quality (because you're undergoing unit testing and integration more often). So, I have authorization configured to allow Contributors to Read, Check In, etc.:

image

In contrast, the Main branch serves as an integration branch. It should be less wild-wild-west but still flexible. The golden rule here is that no code should be directly checked into Main. It should [almost...a few exceptions] always obtain updates through a merge from the Development branch.

Following my typical paradigm, I would enable Check In for the Contributors within Main. However, for this client, we will revoke that permission for Contributors reserving it for Project Administrators (Note: you'll likely need to uncheck "Inherit security settings"). We'll explicitly deny Check In and Lock while Allow'ing Read:

image

Project Administrators retain full rights:

image

So let's take this one step further into the Production branch. Once the team completes integration testing in the Main branch, we start to call on the Release Manager role. S/he owns the Production branch and should treat it as highly restrictive. In theory, merging from Main into Production should be a formality (ok, in reality, we know this isn't the case but go with me here). With this in mind, let's create a third TFS project group named "Release Managers".

image

We'll keep full rights for the TFS server administrators group but restrict Project Administrators to Read rights and prevent Contributors from even seeing this code (just for fun). (Note: You'll need to explicitly add the Release Managers group we created by clicking the Add button.)

Release Managers:

image

Project Administrators:

image

Contributors:

image

Happy merging!

Wednesday, September 03, 2008

Team System Web Access 2008 SP1

Amidst all the .Net 3.5 SP1 and VSTS 2008 SP1 excitement, Team System Web Access (TSWA) got pushed aside. Not to be left behind, the TSWA team announced their SP1 recently.

Installing it this morning, I encountered this error:
"Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."
I posted to the forums about this and it turns out one must uninstall first and then re-install. Maybe I'm the odd one out but I can't recall ever uninstalling to apply a service pack. Regardless, here are the steps I followed:

1. Note IIS settings/configuration:


2. From Add/Remove Programs, remove Visual Studio Team System Web Access. Keep all your settings:



3. Kick off the TSWA MSI installer.

4. When you encounter the existing site conflict, configure to leverage/use the existing site and application pool:





5. I chose Windows authentication but choose whatever is appropriate for your environment:



Afterwards, it took a while for the IIS pool to spin up but TSWA was back and better than ever.