通过TFS 2015 CI/CD部署.dacpac时数据库变更未生效求助

Hey there, let's break down why your new database table isn't showing up even though your build and release pipelines are reporting success. Here are targeted checks to identify the root cause:

1. Verify the Target Database in Your Release Definition #

• Double-check the target server name and database name configured in your TFS release definition. It's easy to accidentally point to a staging/test instance instead of your intended database.
• Look for log entries like Target database: [YourDatabaseName] in the release logs to confirm the deployment is hitting the right place.

2. Confirm the DACPac Contains Your New Table #

• Locate the .dacpac file generated by your CI build. Use Visual Studio's Schema Compare tool to compare the DACPac's schema against your database project—ensure the new table is present in the package.
• Alternatively, use the sqlpackage.exe command line to extract the schema from the DACPac for inspection:

  sqlpackage.exe /Action:Extract /SourceFile:YourProject.dacpac /TargetFile:ExtractedSchema.sql
  

  Open the generated ExtractedSchema.sql file and verify the CREATE TABLE statement for your new table exists.

3. Review Deployment Configuration Options #

• Check if deployment settings are silently blocking changes:
  • Is Block on data loss enabled? While new tables rarely trigger this, it’s worth ruling out if your schema includes other related changes.
  • Ensure Deployment options don’t have settings that skip schema updates. For example, some configurations might ignore new objects if there’s a misconfigured compatibility flag.
  • Look at the Advanced deployment settings for options like Allow incompatible platform—if your target SQL Server version is incompatible, some changes might be skipped without explicit errors.

4. Enable Detailed Deployment Logs #

• Default TFS release logs often only show high-level success messages. Switch the log level to Diagnostic in your release definition, re-run the deployment, and dig into the detailed logs:
  • Look for entries indicating the new table is being processed (e.g., Creating table [dbo].[YourNewTable]) or any subtle warnings about skipped objects.
  • Check the target SQL Server’s native logs (via SQL Server Management Studio > Management > SQL Server Logs) for deployment-related warnings that might not show up in TFS logs.

5. Validate Build Configuration and Code Inclusion #

• Confirm your CI build is using the same configuration (Debug/Release) as your local development. Different configurations might have preprocessor directives that exclude certain objects from the build.
• Open your database project in Visual Studio, right-click the new table’s .sql file, and ensure Include in build is checked in the file properties.

6. Check TFS Version Control and Build Source #

• Verify your new table’s .sql file was successfully committed and pushed to TFS. Sometimes local commits don’t make it to the server, leading the CI build to use an outdated code version.
• In the CI build details, check the Source Version field to confirm the build pulled the code revision that includes your new table.

内容的提问来源于stack exchange，提问作者mohankrishna