Top 7 things to be excited about as a C++ developer in Visual Studio 2017

Redgate Data Tools are now included in Visual Studio 2017, allowing you to extend DevOps processes you already have in place for the application to SQL and Azure SQL databases too. In this demo and Q&A session, you'll see Redgate Data Tools in action to learn more about the challenges and rewards of Database DevOps and how they can increase your productivity when working with SQL.
Find out more details by visiting Redgate Data Tools page.
This seems like a huge step backward. The "Numbered based Migrations" approach have all sorts of limitations that Database Projects solved.
In particular.
Don't get me wrong RedGate make some handy tools, but the "Migrations" pattern common in most ISV tools is vastly inferior & I'm concerned that MSFT might stop developing Database projects as the Dev Team incorrectly assume they have a new product that fits the DBA DevOps need.
Ditto. This looks tossed-in, clunky, and inferior.
@David_Lean: The reverse is true also. "Numbered based Migrations" solves all sorts of limitations that SSDT Deployments doesn't handle.
Add a new NOT NULL column that must contain data not handled by a default.
Split or combine tables.
Reshape data as part of the deployment.
With SSDT you don't know your deployment script until deployment. This leads to all kinds of problems with DBA auditing potentially huge scripts that are unique to the environment.
If you are getting drift in production, there are ways of detecting this on a continuous basis. It's an operational problem, not something to deal with when you are releasing the next version.
If you don't like it, don't use it. But this tool provides the control not possible in the SSDT.
Same opinion here, I prefer SSDT concept over migrations concept, used it in the past with EntityFramework and after hundreds of migrations we started to have serious deployment problems we different client environments we need to upgrade.
Also SSDT support some type of manual migration concept if needed for adding default data, just need to create scripts in a special folder, mark them not to be build and only copied, after that devops scripts can get those and run them along the same SSDT process using sqlpackage.
I have the same concern regarding future of SSDT since this colaboration with RedGate, does this mean developing new features to SSDT will be stopped? (e.g. adding initialization data)
@andreiga76: I'm curious. How do you handle the examples I gave?
> Add a new NOT NULL column that must contain data not handled by a default.
> Split or combine tables.
> Reshape data as part of the deployment.