1. Mistake: treating a data-tier application as only a database. That approach hides related code, users, logins, and deployment artifacts, making automated delivery harder to control. A DAC packages these dependencies with a unique version number for continuous delivery. section 7.6.2
A lift-and-shift migration can also be a costly assumption. Large data-tier applications may contain hundreds of thousands of lines of code in components such as SQL Server Integration Services, requiring re-architecture rather than direct movement to a DBaaS offering. section 1.3
Use these checks when preparing a database for controlled deployment:
- Package tables, procedures, users, and dependent instance-level logins as one versioned DAC. section 7.6.2
- Register the database from SSMS or publish a Visual Studio project as a DAC. section 7.6.2
- Enable deployment blocking when the target database has drifted from the project. section 7.6.2
- Inspect a DACPAC by changing its extension to .zip and reviewing its XML object definitions. section 7.6.2
A versioned deployment package
A Visual Studio database project is built and published with Register As a Data-tier Application selected. The build produces a DACPAC containing XML definitions for the database objects; the continuous-delivery process can then use its unique version and reject deployment if the target has drifted. section 7.6.2
