Troubleshoot a Team Project deletion

A colleague of mines once said “it’s never a stupid question if you don’t know the answer.” So that post might sound stupid, but I had people asking for it hence…there it goes!

You might need to delete a Team Project, and it is a matter of seconds, isn’t it?

It is not always the case, unfortunately. But you can do a lot to understand what goes south. Just using the TFS Admin Console.

Firstly, when you have a DeleteProject job running, you can actually check what it is doing. It is not very intuitive, but if you double-click it, you can access this:

Ok, the job fails. You know what? If you double-click the failed job you can get a very detailed log:

and digging down there you will surely find the reason why the job fails:

That specific case, well…just size your testing environment accordingly, ok? :)

Reducing Technical Debt with Smart Unit Tests

One of the reasons behind Technical Debt is the lack of appropriate test suites around a certain feature. Especially when implementing something new, tests are critical in shaping a robust and quality solution. Often, if you have something in the works and you are not strictly operating TDD, tests are behind where they should be.

Visual Studio 2015 introduced Smart Unit Tests, which are nothing but the former MSR Pex project, rebranded and productised. What Pex/a Smart Unit Test does is to analyse your code and create a basic suite of unit tests to test the basic, border scenarios. Here is an example:

Right click on the method, Smart Unit Tests…

and here is the result:

Of course – this is a really, really basic scenario. What is interesting IMHO is how it is doing it behind the scenes:

as mentioned, it is a full-fledged Unit Test. Very basic, but still a good starting point, saving time while in the works. And if you save it, the Smart Unit Test engine is automatically going to create a new Test Project with the aforementioned tests contained in there. Again, it is not meant to remain as-is (“Sum748” is not a great test name for instance…) but it is still better IMHO than doing everything on my own.

Let’s make things a bit harder now:

That is very crappy code in small scale. No exception management at all, just the plain and down-to-the-bone feature, potentially in development. I can ear people screaming, but it happens extremely often in every organisation. This is the output of Smart Unit Test in this scenario:

It seems I need to spend some time on handling DivideByZeroExceptions and OverflowExceptions, to begin with…

Lab Management and Environments – what to remember

Lab Management’s SCVMM environments are nothing more than a bunch of Virtual Machines running somewhere in a datacentre. Really. I do not understand the reluctancy (almost fear!) when I mention it.

Let’s start with Network Isolation. Network Isolation is an extremely handy feature, allowing a side-by-side deployment of multiple instances of an environment with the same properties (machine name, IP addresses, basically everything which should not be duplicated in a network). It is very cool.

And guess what, there is a clear, step-by-step guide on how to create a Domain Controller VM to be used as a template for a Network Isolated Environment. Basically once you installed the ADDS you need to clean the DNS.

Once you have the VMs ready, I would suggest to compose some environments to be reused without searching for the VM every time. To then enable the Network Isolation, you need to check this checkbox in the Advanced tab of the Wizard:

That is all you need to do. SCVMM will then add a secondary Network Card to the VM to enable this feature, but it is nothing you should worry about.

Also remember that unless you set auto-provisioning, your VMs won’t be automatically shared among the Team Projects in a Collection. You can import them from the library you used to store the template anyway.

One last thing to remember on the VM Templates – always remember to enable the File and Printers Sharing firewall exception, otherwise the deployment would fail, and you won’t be able to connect to the VMs via the MTM Environment Viewer for instance.

If you want an all-in-one reference, have a look at this appendix from Testing for Continuous Delivery with Visual Studio 2012 – even if it is on the older version everything is still relevant. The whole book is actually on the matter, so I suggest to have a look at it. 

Another misunderstood topic seems to be Test Settings. We all have seen the fantastic demos with screen and audio recording, but then all of a sudden you cannot set it up in your lab.

To enable that feature, you need to install the Desktop Experience Feature on your Windows Server VMs:

and then select the Screen and Voice Recorder diagnostic data adapter from the Test Setting you want to use:

Each DDA can be configured to better suit the usage you want, in this case just bear in mind that you are storing big binary files inside the Team Project Collection database, so its size might increase very quickly if you use it a lot. Moreover, there is a number of useful settings you might use:

You can copy specific files (not tied to the Version Control or the build output) to the VMs, run pre and post-test execution scripts, or even force 32 or 64-bit execution in case you need it:

 

Unfortunately the number of resources here is not immense – MSDN is extremely useful as usual, together with the aforementioned eBook, the Visual Studio ALM Rangers Lab Management Guide and the Pro Team Foundation Server 2013 book.

But again, this is not rocket science so you should be good with them.