Site icon TheWindowsUpdate.com

CI & CD With Azure Synapse Dedicated SQL Pool

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Author(s): Pradeep Srikakolapu is a Program Manager in Azure Synapse Customer Success Engineering (CSE) team. 

 

Automating development practices is hard but we can make it simpler using Version Control, Continuous Integration & Deployment and best practices to manage ALM lifecycle of an Azure Synapse Data Warehouse with this blog article.

 

Introduction 

This article helps developers understand the following:

The prerequisites to understand this article are:

 

Note: Synapse Serverless SQL Pool is not discussed in this blog. I will blog about version control, CI/CD for Synapse Serverless soon. 

Version control in DW is achieved by SQL Server Data Tooling (SSDT) with a database project. You can build a database project using Visual Studio, VS Code, Azure Data Studio. I will be using Visual Studio 2022 in this blog.

 

Build & publish database code locally from a developer machine

Create a database project – File> New > Project, choose SQL Server Database Project template

 

 

Once the database project is created, right click on the project in the solution explorer. You should choose the target platform as “Microsoft Azure SQL Data Warehouse”.

 

 

Organize the database project in the same way we organize the objects in SSMS.

 

 

In the above screenshot, see that I organized schema files in Security -> Schemas folder. I also organized tables and views for each scheme for better abstraction like SSMS with minor differences. Please make sure to include .sql files as part of your build by configuring the build action property to “Build” and copy to output directory property to “Do not copy”.

 

 

You can build the DACPAC file by building the database project from context menu or the entire solution by F5. The context menu of database project has an option build to compile the database project into DACPAC file. 

 

 

 

SSDT + SQL Database projects use MS build to compile the source code and extract the DAC package file (DACPAC file). If you unzip/unpack DACPAC file, you will see DacMetadata.xml, Origin.xml, model.xml, and model.sql files. model.sql and model.xml files are the representation of your database model.

 

 

Once you build a DACPAC file by building database project, you can deploy it to the target data warehouse using SQL Package – Publish action either via database project or SQL Package.exe from cmd.

 

 

You need to configure the target database configuration to deploy the DACPAC file. The other way is to use SQL Package file. An example:

 

 

SqlPackage /Action:Publish /SourceFile:"C:\Users\pvenkat\source\repos\AzureSynapseDW\DWSSDT\bin\Debug\DWSSDT.dacpac"  /TargetConnectionString:"Server=tcp:pvenkat-test-ws.sql.azuresynapse.net,1433;Initial Catalog=testsqlpool;Persist Security Info=False;User ID=dbttestuser;Password={};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"

 

 

 

Continuous integration - Build & deploy database project with Azure pipelines 

As a developer, you can build data warehouse code and publish it locally. What if you need to deploy the database code to a development or a test or a production environment? We wouldn’t want to manually deploy source code to any environment. The answer to this problem is to enable continuous integration and deployment on the source in Azure DevOps using Azure pipelines or GitHub using Actions. In this example, I will share the source code repository and the Azure pipelines to enable CI & CD aspects of database code development and deployment. 

 

Add a YAML file to your source code to perform three tasks. I am using multistage Azure Pipelines to show these three tasks.

 

Build Database Project & Publish Artifacts 

 

 

- stage: Build
    jobs:
    - job: Build_And_PublishDatabase_Project
      steps:
      - task: NuGetCommand@2
        displayName: 'NuGet restore'
        inputs:
          vstsFeed: 'ebdcf40d-0db5-427e-b3c5-32b9cb5dcb8d'

      - task: VSBuild@1 
        displayName: 'Build solution DWSSDT/DWSSDT.sqlproj'
        inputs:
          solution: DWSSDT/DWSSDT.sqlproj

      - task: CopyFiles@2
        displayName: 'Copy binaries to staging directory'
        inputs:
          SourceFolder: '$(System.DefaultWorkingDirectory)'
          Contents: '**\DWSSDT\**\bin\**'
          TargetFolder: '$(build.artifactstagingdirectory)'

      - task: CopyFiles@2
        displayName: 'Copy dacpac tools to staging directory'
        inputs:
          SourceFolder: dacpactools
          TargetFolder: '$(build.artifactstagingdirectory)\dacpactools\'

      - task: PublishPipelineArtifact@1
        displayName: 'Publish Pipeline Artifact'
        inputs:
          targetPath: ' $(build.artifactstagingdirectory)'
          artifact: drop

 

 

 

 

Verify DACPAC & compare with target data warehouse 

Verify stage is verifying the contents of the dacpac that are about to be deployed. 

 

 

- stage: Verify
    jobs:
    - job: Verify_DW_Package
      steps:
      - download: current
        artifact: drop
      - task: SqlAzureDacpacDeployment@1
        displayName: 'Verify '
        inputs:
          azureSubscription: 'Pradeep-MSFT Personal Use (f4664abe-17d0-4128-8048-150cd01575b4)'
          ServerName: 'pvenkat-test-ws.sql.azuresynapse.net'
          DatabaseName: testsqlpool
          SqlUsername: dbttestuser
          SqlPassword: '$(PASSWORD)'
          DeploymentAction: Script
          DacpacFile: '$(Pipeline.Workspace)\drop\DWSSDT\bin\Debug\DWSSDT.dacpac'

 

 

 

Deploy DACPAC using SQL Package 

Deploy stage publishes the DACPAC file to target data warehouse. Publish action generates the differential script between DACPAC and target data warehouse and then deploys the differential script to the target data warehouse. 

 

 

- stage: Deploy
    jobs:
    - job: Deploy_DW_Project
      steps:
      - download: current
        artifact: drop
      - task: SqlAzureDacpacDeployment@1
        displayName: 'Azure SQL DacpacTask'
        inputs:
          azureSubscription: 'Pradeep-MSFT Personal Use (f4664abe-17d0-4128-8048-150cd01575b4)'
          ServerName: 'pvenkat-test-ws.sql.azuresynapse.net'
          DatabaseName: testsqlpool
          SqlUsername: dbttestuser
          SqlPassword: '$(PASSWORD)'
          DacpacFile: '$(Pipeline.Workspace)\drop\DWSSDT\bin\Debug\DWSSDT.dacpac'
          AdditionalArguments: '/p:AdditionalDeploymentContributors="AgileSqlClub.DeploymentFilterContributor" /p:AdditionalDeploymentContributorPaths="$(Pipeline.Workspace)\drop\dacpactools" /p:AdditionalDeploymentContributorArguments="SqlPackageFilter=IgnoreSchema(sch_1)"'

 

 

 

 

Selective Deployment – Publish Action 

SQL Package, publish action support several additional parameters to ignore objects by type. Parameters such as DoNotDropObjectTypes, DropObjectsNotInSource, ExcludeObjectTypes and other properties in SqlPackage Publish - SQL Server | Microsoft Learn lets you selectively deploy the object type(s) of your choice. However, SQL Package does not selective deployment of specific objects by name, regex expressions. Many customers with a large data warehouse (>2000 objects) are having trouble deploying DACPAC solutions without specifying object name(s).  

 

GitHub - GoEddie/DeploymentContributorFilterer provides an alternative to filter objects by name/regex expressions as part of dacpac deployment. Please provide Additional arguments to Publish action - AdditionalDeploymentContributors, AdditionalDeploymentContributorPaths, AdditionalDeploymentContributorArguments to apply filters before DACPAC deployment.

 

 

 

AdditionalArguments: '/p:AdditionalDeploymentContributors="AgileSqlClub.DeploymentFilterContributor" /p:AdditionalDeploymentContributorPaths="$(Pipeline.Workspace)\drop\dacpactools" /p:AdditionalDeploymentContributorArguments="SqlPackageFilter=IgnoreSchema(sch_1)"'

 

 

 

 

AdditionalDeploymentContributorArguments takes filters as an input to ignore/filter/keep the objects as part of DACPAC for publish action.

 

 

Our team publishes blog(s) regularly and you can find all these blogs at https://aka.ms/synapsecseblog.

 

For a deeper level of understanding of Synapse implementation best practices, please refer to our Success by Design (SBD) site: https://aka.ms/Synapse-Success-By-Design

Exit mobile version