Comments
5 comments
-
Maybe this is a silly question, but have you made any changes or are the source package and target database already in an identical state?
-
Nothing's a silly question except maybe mine
They are in different states, I've validated with SQL Compare and checked that the logs are pointing to the correct targets.
Steps for build:
DLM Build from latest SOC version to Package
I can validate that the generated package is good (has the changes I want)
Release
DLM Release (both from package and create database release) will show that they're comparing against my target DB and both end up showing the no updates. I got one or two to work and if I make a migration script then it works but it won't transfer state, these are new procs so I'd expect it to be the easiest scenario. I'm sure I'm missing something simple.
-
Little bit more info, it appears the disconnect is in the Deploy Release step, the release is setup and has the source/targer files (and they differ). Update.sql says:
This script is empty because the Target and Source schemas are equivalent after applying the filter in package file
Seems pretty straightforward but the filters are really, really low and don't contain procs/schemas that should not be promoted/excluded. -
The filter.scpf file in source control is correct, the one in my nuget package is empty, it has includes and I'm assuming it's not comparing anything, thus not generating a script. I had left everything as default assuming it would grab the Filter file automatically for comparisons.
-
Whew, ok, so, I'd done a build or two and release prior, then installed SQLTest/SQLCop and decided to see if it would roll through the release management but it didn't. I added my own test schema (UnitTest) and it didn't, that's when I went down this rabbit hole and opened this comment.
Turns out, there's a default option for IgnoreTSQLT in the build (in the XML config file that's generated), I added the -IgnoreTSQLT switch to my release SQL Compare Options and bam, it all went through. Interesting that my own schema was ignored, I'm guessing because it contains that word "test".
Thanks for the help!
Add comment
Please sign in to leave a comment.
The update script doesn't contain any SQL statements. Skipping the update.
And nothing is actually deployed, unless I use a migration script for every step which doesn't appear necessary.
This is SOC->TFS on prem using DLM