What is the best practice of setting the DacUpgradeOptions.IgnoreDataLoss property in automatic Data-Tier Application (DACPAC) upgrades?
Based on the MSDN documentation (link), if IgnoreDataLoss is True, the upgrade will proceed even if some of the operations result in the loss of data. If False, these operations will terminate the upgrade. For example, if a table in the current database is not present in the schema of the new DAC, the table will be dropped if True is specified. The default value for this is True.
However, in the environment with continuous delivery where every database change is automatically deployed all the way up the pipeline (CI -> Test -> UI-Test) and eventually to Production environment, it seems like a safety measure to set IgnoreDataLoss is False, because we would not want data loss/drift to occur on the Production database. If IgnoreDataLoss is False and a developer commits a database change that introduces data loss, the CI/Test build will fail, allowing us to catch this before this change reaches Production.
There’s a problem with this approach though, as there are times when data loss is intentional. For example, we might need to delete a specific table that’s not being used anymore. If IgnoreDataLoss is False, this will fail the build and the DACPAC changes are never applied, because potential data loss is detected (even though such loss is intentional). In this scenario, we would want IgnoreDataLoss to be True.
Just wondering what would be the best practice for this, especially in an environment where we are deploying continuously and automatically. Any suggestion would be greatly appreciated. Thanks!
In most cases, we can set IgnoreDataLoss to false. This helps to ensure we don’t accidently modifies the database and introduce data loss. When we want to delete a table, we can either manually delete the table (please do not use DACPAC). Or we can temporary set IgnoreDataLoss to true for that particular upgrade operation.
Best Regards,
Ming Xu.