Break it, fix it

One of my clients wanted to include the current iteration name in the build number format. I created a PowerShell script to retrieve it into a build variable named Build.PackageVersion $Uri = "$(System.TeamFoundationCollectionUri)/$(System.TeamProject)/$(System.Team)/_apis/work/TeamSettings/Iterations?`$timeframe=current&api-version=3.0" $Response = Invoke-RestMethod -Method Get -UseDefaultCredentials -ContentType application/json -Uri $Uri $IterationName = $Response.value.name Write-Host "##vso[task.setvariable variable=Build.PackageVersion;]$IterationName" The System.Team variable is a custom one to avoid hard coding inside the script.  The script is executed via a build task from the marketplace:  https://marketplace.visualstudio.com/items?itemName=ms-devlabs.utilitytasks Then I used the tasks from Jesse Houwing to update the build number at build time: https://marketplace.visualstudio.com/items?itemName=jessehouwing.jessehouwing-vsts-variable-tas

It is not supported to add READONLY or FROZEN rules on the System.IterationPath and System.AreaPath. A work around is to create a custom field named "You cannot change this field" for example. Give it the Integer type. In the "Rules" tap, add one WHENCHANGED rule for each field you want to protect. In the first one, select System.AreaId in the Field Condition, and navigate to the Rules tab. Add two rules: COPY For: the TFS group containing the users not authorized for change From: value Value: leave empty REQUIRED For: the TFS group containing the users not authorized for change Do the same for the second WHENCHANGED rule for System.IterationId Basically, the following sequence will trigger when an unauthorized user tries to change a protect field (System.AreaId and System.IterationId linked respectively to System.AreaPath and System.IterationPath) : The field value is changed to blank The field is set to REQUIRED This triggers a validation

In case you need to connect subnets in different Azure subscription, you might come across the following (nice) article: https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ I just wanted to give a little more information based on my experience with the actions involved. If you try to follow the steps to connect the subnets using pre-existing gateways, it will not work. You have to create the gateways using the provided instructions. I suppose it is due to the fact that gateways created from the Portal have the "Basic" SKU (you can see it using the Resource Explorer). The PowerShell instructions include a specific parameter named SKU and we have to pass the "Standard" value. At the time of the writing it is not possible to pass this parameter in the Portal, hence the need to use PowerShell to create the gateways.

You might find yourself having to track down bad practices (like modifying the original estimate of a task). You could setup an alert to be notified as soon as it happens or you can monitor changes through the TFS database. Today, I'll explain how to monitor using a query on the TFS database. We will use the collection database. The idea is to use the views related to work items and their history. The first step is to union the data sets (the current work item states and the past work item states). Then we select the record having an original estimate higher than the previous version. THAT is the tricky part. I used the LAG analytic function to get the reference to the "previous" record (that is, the same id but the previous revision). Here is the complete statement. WITH AllData AS (   SELECT *     FROM [Tfs_DefaultCollection].[dbo].[WorkItemsAreUsed]    UNION *     FROM [Tfs_DefaultCollection].[dbo].[WorkItemsWereUsed] ), AllDataWith Lag AS (   SELECT *    

If you find yourself having to create diagrams for Cloud architectures in Visio, there are nice stencils from Microsoft with all the Azure services ! Here is the download link

I recently decided, for a specific team project, to use the Description field instead of the Repro Steps field in the Bug work item. The main reason is to be able to create reports for both Product Backlog Items and Bugs, while being able to display the full description. The first step was to migrate the content of the Repro Steps field into the Description field in order to retain data for existing items. Since it is not possible to do field-to-field bulk update from the Web interface, I had to create a small console application to copy the data. The main problem I encountered was about inline images. When you copy and paste a screenshot into an HTML field, it creates an img tag with Base64 data in the src attribute. For an unknown reason, when the data in the src exceeds a certain limit (I don't know the actual value), the src attribute is blanked during the save. Images simply appear blank in the target field. After some search, I came across this post from René van Osnab