Why are all programmable objects deploying (deploy) to a target DB that is already baselined?
PeterDanielsCRB
Posts: 126 Bronze 3
I made a SCA project with a baseline from our prod DB which has >6000 programmable objects. I made a couple of minor migrations, and now I'm using the powershell cmdlets to validate the build, make a build artifact, and make a release artifact for deployment. ALL of the programmable objects are in the release artifact's TargetedDeploymentScript.sql. I do not want ALL of the programmable objects to deploy. I would think only the ones that have changed should deploy. Advice?
Thanks,
-Peter
Thanks,
-Peter
Tagged:
Best Answers
-
Nick_Foster Posts: 17 Bronze 2PeterDanielsCRB said:What if I hacked it by creating a __MigrationLog table and copying the data over from the dev DB?
-
Ivo_Miller Posts: 31 Silver 3When the baseline script is generated, nothing is written to the target database used for the baseline. It is safer for that to be a read-only operation. Users might need to edit the baseline script, or associated programmable objects, before proceeding.
The consequence of this is that we have no concrete record of the database state used to generate the baseline, so don't really have a simple basis upon which to mark the programmable objects as applied rather than adding them to the script.
There is a flag, "BaselineAllDeployChangesMigrations", which can be used to mark all programmable objects as applied instead of deploying them, but it should be used with caution, as it only makes sense when deploying the baseline and nothing more. Currently the only way of setting it is by adding <BaselineAllDeployChangesMigrations>True</BaselineAllDeployChangesMigrations> to the project file. It needs to be set to false (or removed) for any subsequent changes to the programmable objects to be handled correctly.
Hacking it by copying across the __MigrationLog table should work.Ivo Miller
RedGate Software Developer
Answers
Currently, it is not possible to change this behavior, I will pass your feedback to the development team to see if this is something that we can improve on in future releases.
Kind Regards,
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools
Just to qualify this. When a release artifact is generated only the programmable objects which have not been deployed should be included in the release artifact script.
If it is the very first deployment to the target database, then the __MigrationLog table will not yet exist in the target database, so these scripts will be included in the deployment script, as they will not yet have been marked as deployed.
RedGate Software Developer
I'll make some more comments here when it's time to go to prod. Hmmm. I just looked at prod, and it doen't have a __MigrationLog table, so I'm assuming it will want to redeploy all 6000+ objects there, too. Wondering why there is no __MigrationLog table in the prod DB that we used for the baseline/target when I created the project?
What if I hacked it by creating a __MigrationLog table and copying the data over from the dev DB?