Introducing Redgate Data Tools in Visual Studio 2017

The Discussion

• 

  This seems like a huge step backward. The "Numbered based Migrations" approach have all sorts of limitations that Database Projects solved. 
  In particular. 

  1. Ability to compensate for "drift" in Production systems. eg: Changes to production that didn't go thru the release process that cause the new release scripts to fail. (not supposed to happen in a rigorous DevOps shop, but does.)
  2. The inability to detect that some "migrations" make some older Migrations redundant. eg: Migration 10 adds a column, Migration 12 Indexes the column, Migration 31 drops the table as it is no longer required. (You still have to execute all of them even though only the last change is needed.)
  3. Using the query parser of a real instance of SQL Server to validate & generate the correct SQL for the SQL Target (Retail SQL or Azure DB)

  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.