Last month in SSMS v22.4, we had the Database DevOps (preview) workload introduced which brings with it Database Projects. Last week I shared my favourite features for them which make deployments amazing.
But if you’ve tried them out in SSMS you might have noticed that not everything is present. It’s a preview, after all. So what can we do today?
In this post I want to quickly explain why we are where we are with a history of projects, followed by reviewing what is in and out currently for the SSMS preview, and then what you can do right now if you’re starting out with Database Projects.
Let’s jump in.
Brief history
If you’re new to Database Projects check out this demo (in SSMS) from Drew for a good intro.
Database Projects have been available in Visual Studio for years under the SQL Server Data Tools (SSDT) extension. If you’ve used them before, you’ll know how established they are.
More recently, they’ve been getting reworked into a lighter SDK-style version which appeared in Visual Studio 2022 as a preview, along with VS Code. The VS Code implementation has evolved over the last couple of years to have near feature parity with the original version.
This year the Database Projects workload has moved its preview from Visual Studio into SSMS to better align with data tooling. The feature set trails behind other implementations, so it feels under-cooked compared to VS Code or the original SSDT experience.
Now we understand why we have different experiences, let’s take a look at what’s actually in, and what’s missing.
What’s in and out
The core experience of Database Projects – creating, building, and deploying – is all present and works well for the core workflow. If you just need the basics, you can pick your tooling of choice.
Let’s start with some headline features of what’s in and out, including my top 3 from last week:
- ✅ Building and deploying – bread and butter, good to go
- ✅ Scripts – pre and post scripts are available in all flavours
- ❌ GUI designers – no table designer or schema compare
- ❌ Publish profiles – available everywhere but SSMS 😢
- ❌ Refactoring – not available, currently exclusive to Visual Studio
- ✅ Package references – one of the few features exclusive to SDK-style projects. We’ll cover these another time
It looks like a mixed bag, but the SSMS team are coming out strong. The workload only landed into preview in March (v22.4), with more features added in April (v22.5), and they’ve teased more on the horizon.
If you want to check out a full feature set comparison they’re listed out in full here.
The key takeaway here is that this is a preview. This isn’t the finished article, and there’s a way to go before we have meaningful parity across the tools. The different implementations aren’t different tools, they’re the same tool at different levels of maturity.
For example, whilst support for the publish profiles we saw last week isn’t there yet, it’s already available in VS Code and will likely arrive sooner or later. Refactoring on the other hand is still only available in the legacy SSDT implementation so that’s up in the air.
For this reason it’s important to consider what we can do now to be in the right place as the solution matures.
What can we do now?
Having multiple tools available – all with different levels of implementation – doesn’t help the case for adoption.
- SSDT is mature and complete but its legacy tooling may get left behind
- VS Code is modern and feature rich but not a familiar environment for most data professionals
- SSMS is daily tooling for data professionals, but features are lacking and parity will take time
This leaves us with a difficult choice.
Personally I’d still advocate starting with Visual Studio (the Community edition is free) and learn the projects through there. Yes, it’s the ‘legacy’ choice, and it wouldn’t be as lift-and-shift to migrate to SSMS like VS Code. However, with Visual Studio you’re getting the familiarity of GUI editors and a complete feature set from the get-go.
I’d love to say dive in with SSMS, but given we’re only 6 weeks into a preview, it’s too early to recommend as the primary tooling for new projects. Ultimately I think that’ll be the direction as it’s the go-to data tooling. Just not yet.
With that said, one of the beauties of database projects is that the most important part for us – the code (tables, views, procs, scripts) – is transferable between projects, so if the tooling matures or there are features we need elsewhere, there’s the option to at least manually migrate.
Wrap up
The arrival of Database Projects in SSMS is a big step forward. I know folks who’ve avoided them before due to the foreboding Visual Studio environment, so having the tooling available in a familiar environment makes them approachable.
But it’s not complete.
For simple workloads and environments, there’s enough functionality to get stuck in with. The feature set trails the established Visual Studio, with some catching up to its older VS Code sibling. Crucially, these aren’t 3 different tools – they’re different flavours of the same tool. The choice is really what feature set and level of maturity fits your situation.
We can’t lose sight that this is a preview – and an early one at that. For all the drawbacks of using it now, it’s well positioned to become a first class workload within SSMS.
It’s just not quite there (yet).
Andy Brownsword 