MicrosoftThank you for the post. In your response to MinhDNguyen I understand your perspective but there are still issues with that approach. There are valuable insights that we lose when we don't maintain lineage between main and our releases, like user story/task/bug tracking. Right now, this is proving to be challenging, because when I link and track changes with my release pipeline, I lose all insight on the release, but I can track those changes for my database project for the Synapse dedicated SQL Pool, maintained in a separate repo with independent build and releases. My concern is that for larger teams where we have policy protected branches, we lose the ability to merge these changes back into main with the manual publish, to do this we would need an additional pull request. The Azure Data Factory team has a much better approach to this issue. https://docs.microsoft.com/en-us/azure/data-factory/continuous-integration-deployment-improvements I think the biggest advantage to an approach where we leverage a more traditional build pipeline is that it empowers the engineering team to leverage the most appropriate branching strategy for their teams and is more suitable for managing hotfixes without a ton of manual work to deploy changes.
