If you’ve ever run a database package (.dacpac) publish against a SQL Server or Azure SQL database, chances are good that you have run into the following error when changing the schema for a table that contains data:
SQL72014: .Net SqlClient Data Provider: Msg 50000, Level 16, State 127, Line 6 Rows were detected.
The schema update is terminating because data loss might occur.
Azure Resource Manager (ARM) templates have a nice set of built-in functions that allow you to develop complex expressions. These expressions can help a static deployment template file become more scalable and flexible for different scenarios. This article is a quick rundown on my new favorite tip for debugging a template expression that you just can’t get working.
Normally we use SDKs to interact with Azure. Things like the Azure .NET SDK, the Azure PowerShell module, or the dozens of other SDKs listed here can be used. These SDKs provide a lot of helpful utilities and validation, but ultimately they will hit the Azure REST API once they need to phone home. Azure’s REST API provides this all-important foundation to write code against the platform.
Today we are going to walk through a helpful modification to the Visual Studio Team Services (VSTS) process and style templates; with the goal of making it easier to find and visualize blocked work.
Note: This post was written right before VSTS re-branded as Azure DevOps. For new instructions for Azure DevOps, visit this link: https://keithbabinec.com/2019/10/08/how-to-visually-highlight-blocked-work-items-on-an-azure-devops-sprint-board/