Customizing deployments of a SQL Server Data Tools (SSDT) package using sqlpackage.exe to vary per environment

Question

I have a SQL Server Data Tools (SSDT) .sqlproj files that contains, among other things, a Table Type like the following:

CREATE TYPE [dbo].[tableType] AS TABLE
(
    [id] uniqueidentifier INDEX [idx],
)
 WITH  
        (MEMORY_OPTIMIZED = ON); 

I am deploying this project to Azure SQL. The problem is that my test databases are Azure SQL standard (as opposed to premium or business critical). As a result, they don't support memory-optimized tables. So what I am trying to figure it out is a way to deploy the type without memory optimization in test, and with memory optimization in production. Command line switch, env variable, whatever works. I am deploying with sqlpackage.exe, but I'm open to other approaches to make this possible.

Answer 1

I would give a try SSDT SQLCMD variables:

SQLCMD Variables

In SQL Server Database Projects you can utilize SQLCMD variables to provide dynamic substitution to be used for debugging or publishing. You enter the variable name and values and during build, the values will be substituted. If there are no local values, the default value will be used. By entering these variables in project properties, they will automatically be offered in publishing and are stored in publishing profiles. You can pull in the project values of the variables into publish via the Load Values button.

Make sure the right variables are entered in project properties, because these variables are not validated against a script in the project, nor are the variables used in script automatically populated.

^{Image src: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/30895c7f-9a49-4fab-b3d1-b690fff82792/sqlcmd-variables-not-recognized-by-ssdt-build-fails-when-these-are-used-in-a-script}

CREATE TYPE [dbo].[tableType] AS TABLE
(
    [id] uniqueidentifier INDEX [idx],
) $(param_name);

And during publish it could be defined as:

TEST - empty
PROD -  WITH (MEMORY_OPTIMIZED = ON); 

Altough I strongly recommend to upgrade test environment.

Answer 2

As this is environment specific, I would suggest you to choose one of the below approaches:

You can have three approaches:

1. As @Lukasz Szozda suggested, you can have SQLCMD variable. Define SQLCMD variable and mention the environment. Based on environment, you can decide which script to execute in your post deployment script.

IF '$(Environment)' = 'Prod'
        BEGIN
            :r .\ProdSpecificScript\Prod_TableTable.sql
        END
        ELSE
        BEGIN
           :r .\NonProdSpecificScript\NonProd_TableTable.sql
        END 

2. You can update Project file with below information, to overwrite Postdeployment script with different file, based on the environment. You can have two different post deployment scripts with different TableType script.

<Target Name="BeforeBuild">
      <Message Text="Copy files task running for configuration: $(Configuration)" Importance="high" />
      <Copy Condition=" '$(Environment)' == 'Prod' " SourceFiles="Scripts\Post-Deployment\Default.Script.PostDeployment.sql" DestinationFiles="Scripts\Post-Deployment\Script.PostDeployment.sql" OverwriteReadOnlyFiles="true" />
      <Copy Condition=" '$(Environment)' == 'NonProd' " SourceFiles="Scripts\Post-Deployment\Default.Script.PostDeployment.sql" DestinationFiles="Scripts\Post-Deployment\Script.PostDeployment.sql" OverwriteReadOnlyFiles="true" />      
  </Target>

3. You can check Azure Service tier and accordingly decide the script.

DECLARE @ServiceTier VARCHAR(30)
SET @ServiceTier = (SELECT COALESCE(DATABASEPROPERTYEX(DB_NAME(), 'ServiceObjective'), 'N/A in v11') AS AzureTier FROM sys.database_service_objectives

IF @ServiceTier = 'P1'
BEGIN
    :r .\ProdSpecificScript\Prod_TableTable.sql
END
ELSE
BEGIN
   :r .\NonProdSpecificScript\NonProd_TableTable.sql
END