MicrosoftThis is kind of useful, but unfortunately only in a limited way... if you literally want to just replicate your serverless objects then this is great. However, for me serverless is cool but out of consideration for real production work and only useful as a kind of adhoc data query tool mainly in dev. I really don't want to script out all the objects and faff around with deploying them to other environments like others have done...
I agree with the questions posed by jacovg91 there are still 2 issues that hold serverless back from being 'perfect' for me:-
1) Still can't use SSDT, Visual Studio 2022 or other tools to keep this under source control, e.g. in a database project
2) Only works if your development external data sources point to the same place as your production (or other environment) external data sources do. If your organisation is like ours then this is highly unlikely to be the same place, for example we have a dev datalake and and prod datalake. So in this case you'd have to run some sort of dynamic SQL after deployment to drop/create the external data sources so they're pointing to the correct places, but this defeats the point of replicating them from dev in the first place. Note that this is a challenge even in dedicated SQL pool, but there we use some dynamic SQL with 'COPY INTO' to get around this problem instead of using external tables, but that's not possible in serverless.
If these could be sorted out and we'd use serverless in production, which would be great... So near, but so far, sorry...
