Am I missing something, or did MS kludge this:
Q1: Should I just add the projname.sqlproj.user file to source control?
Q2: Should I somehow incorporate a .publish.xml file into the build step?
Bonus Q: What's happening on the build server in the absence of the .sqlproj.user file that contains all those critical flags?
Background:
At my large enterprise, my team has it's first working CI/CD pipeline to deliver a .sqlproj to a sql db using the .dacpac generated by the build server. It's working and I'm learning the dacpac ropes.
I'm playing with the flags that stand between my team and disaster (i.e. DropObjectsNotInSource=false), and git isn't seeing the changes in the .sqlproj file. It becomes evident that these flags are stored in a .user file and not the .sqlproj file!? (projname.sqlproj.user)
Normal practice is to .gitignore *.user files, and MS knows this, so am I crazy? I don't want a newer dev to start playing with flags and never see the change in SC.
Additional background
One of our goals is to have all publish events handled through ci/cd pipeline; so we don't really want an open path to manually/directly publish changes even to Dev env. Too many of the long-term developers have the extremely bad habit of skipping Dev env entirely and going straight to QA then Prod. So we may need to shock them out of that by denying personal Alter/Control access definitely in QA/Prod, but maybe even in Dev env.
Stack:
VS2017 (2019 is an option)
SSDT
GitHubEnteprise
TeamCity
Octopus
SQLServer2016
That's a "publish.xml" or publication parameters/profile setting. When we were shelling out to sqlpackage.exe, we'd include the option for the appropriate Publish Profile that had those settings. You can also set it at the command-line level. It's definitely not a *.user file setting.
That said, I also will typically include those Publish Profiles in the project for the devs to use (local, dev, whatever) so they can double-click one of those and start that local/dev build using the pre-defined settings. (usually with a warning like - look at the preview before hitting "publish" by gen'ing a script) We can then include those publish profiles in our deploy/publish action.
Only warning if you go that route is that if you use a "Publish" folder, you'll probably need to tweak your .gitignore. That folder name is ignored by default for Visual Studio projects if you're using the gitignore repo files.