Last week I posted about how to integrate TFS and Project Server “manually”. In the post I did put in a bit of philosophy about why I think project plans can be a Bad Thing. Prasanna Adavi posted a thoughtful comment on my philosophy, and I wanted to reply just as thoughtfully, so I decided to add the reply as a new post rather than just reply to the comments inline.
I often do road-shows showing off TFS and VS to customers around South Africa. Usually I’m doing this with Ahmed Salijee, the Developer Platform Specialist (DPS) for Developer Tools in Microsoft South Africa. Ahmed is an amazing speaker (we’ve co-presented regularly) and is great at helping customers at a strategic level – and, as he likes to say, for his sins, he gets to help customers with their licensing queries!
If you’re using WebDeploy and Release Management (as you should to release Web Applications) you may hit the following error:
At a customer we installed Release Management for their TFS 2013 TFS Server. The server component installation went really smoothly – however, it was only when we installed the Client that we realized that the Release Management service was not right – we kept getting a 503 Service Unavailable error. I opened IIS and could see that the Release Management application pool was stopped. I started the app pool, but it immediately shut down. We checked the event log and saw a few obscure error messages about NullReferenceExceptions – nothing particularly helpful.
I have been doing some coded UI testing and running tests using Chrome (via the Selenium components). However, I noticed that when my test completed successfully, the Selenium (ChromeDriver) window stayed open and never terminated. Here’s a code snippet of my original code:
Yesterday I posted about how to create script hooks in a 2012 build template. My colleague Tyler Doerksen commented and pointed out that there was no error handling in my solution.
EDIT: My colleague Tyler Doerksen pointed out in his comments that my solution doesn’t do any error checking of the scripts. If your script fails, the build happily continues. I’ve added another post to show how to add error handling.
I’ve just completed recording a Release Management webcast (more on Imaginet’s Visual Studio webcasts here). While doing the webcast, I wanted to show how you can use tokens which Release Management can substitute during the Release Workflow. Brian Keller suggests a .token file (basically an exact copy of your web.config file except that you use tokens instead of values) in his Release Management hands on lab, but I hate having to keep 2 copies of the same file around.
If you’ve upgraded to TFS 2013, then you’ll notice that there’s a new Default Build template. In fact, to support Git repositories, the product team moved the default template into a super-secret-database-backed-folder-you-can’t-get-hold-of-place in TFS. This means that you won’t see it in the BuildProcessTemplates folder.
If you have Visual Studio Ultimate and are not using IntelliTrace in production, you should be drawn and quartered. This is arguably the best feature of Visual Studio Ultimate, and in my opinion this feature alone justifies the pricing (never mind Web Performance and Load testing, Code Maps, Code Lens, UML diagrams and Layer diagrams).
