This is going to be a short one because I’ve been working hard all evening on this, and frankly I’m a little tired. But I’ve made a change to PoshSSDTBuildDeploy which is going to be the start of more changes. Intrigued? Well, read on…

Making Use of The Deployment Report

So! One of the neat options available when pushing a change via SSDT is to create a Deployment Report. In short, it’s an xml file that summarises the changes that are going to be made as part of a deployment. Here is a sample one -

<?xml version="1.0" encoding="utf-8"?>
  <DeploymentReport xmlns="http://schemas.microsoft.com/sqlserver/dac/DeployReport/2012/02">
    <Alerts />
        <Operation Name="Create">
          <Item Value="[dbo].[TestOne]" Type="SqlTable" />
          <Item Value="[dbo].[TestTwo]" Type="SqlTable" />

The Report above is telling us that there are two tables being created. This is a small change, yet in most deployments there are a lot more than one. Ideally the number of changes should be as small as possible, however that’s not always the case. And also there can be a number of changes you’re not expecting to see (like foreign keys always being rebuilt). And so a .sql file can be difficult to read. and to understand what changes are in the file. So it makes sense to make use of the deployment report and sumarisethe changes via PowerShell.

If a Deployment Report is generated there are two pscustomobjects created that summarise the operations and the number of those changes in a deployment. For the report above they look like this -


There’s a lot of scope for adding more to this (see the Deploy Report used for the Pester test and why we may want to raise warnings for odd changes, and also point devs to use the refactorlog), but for now this is a good first shot at this.

Latest version is now on PowerShellGallery. PoshSSDTBuildDeploy