Advocate II can also see a need for pre-deployment script (pipeline or notebook would be preferred).
For example, today you can't deploy Incr. Refresh with Detect Data Changes via the deployment pipeline because you can mess up the "refreshBookmark" for each partition. This is the hidden date (can be anything, but usually a date) that is unique to each partition based on the max value when that partition was last refreshed. Those dates are likely different between say, DEV and TEST because you may be looking at different data (DEV is an infrequently refreshed subset of data, UAT is closer to real time PROD data for example).
So for larger models, if these dates get reset it may mean at the next refresh it would look like they need to refresh a bunch of old partitions and that could be too large and cause errors. A pre-deployment script could read the values in TEST, store them in a file, then post-deployment write them back to the TEST after deploying from DEV. Then the script could kick off a refresh or recalculate event.
This is one example for a pre-deploy script, I can imagine others.
For this particular case (IR with DDC), Microsoft should just make it compatible with deployment pipelines and not overwrite the bookmarks in TEST for example. See this idea: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Deployment-Pipelines-Support-Incremental-Refresh-with-Detect/idi-p/4716846
