I have released another tool as part of the ssdt dev pack, what this does is create tSQLt classes and stub tests. If you open a stored procedure in ssdt and then do “Tools–> SSDT Dev Pack–> Create tSQLt Class” or you can create a keyboard mapping in “tools->options->keyboard”, what I do on my machine is map “Tools.CreatetSQLtClass” to Ctrl+K Ctrl+S - it will create a schema with the name of your stored procedure and the correct extended property for tSQLt to register it as a test class.

Automatically name primary key constraints There are some things you see when writing t-sql code and schemas that just look sloppy, one of those is unnamed constraints, what you see is: create table t( id int not null primary key ) The problem with this is that the primary key is given an automatic name which will look like “PK__t__3213E83F5F141958” - this means comparing database schemas for differences becomes hard as the constraints have different names.

I have made some changes to the way MergeUi works and also moved it into a new repository (https://github.com/GoEddie/SSDT-DevPack). The way MergeUi used to work was that it enumerated the schemas and tables in a project and let you create a merge statement in the post-deploy script. The problem with that is that you may want to have different versions of the table for different environments or you may want to put the merge in a different script and either reference it using :r imports or not reference it at all.

What is the ScriptDom? The ScriptDom is an api for taking t-sql scripts, converting them into an AST or taking an AST and generating t-sql. What is an AST? Read this: https://en.wikipedia.org/wiki/Abstract_syntax_tree Think about this: select col from tablea select col from tablea select col /*from not_table*/ from tablea select –not_col col from tablea and then something more complicated like: select col from (select a as col from something /*else*/) a

I have made a few ui changes to this to make it a little more usable, I can’t really think of any new features so if anyone has any ideas let me know :) New version (slightly prettier): https://github.com/GoEddie/ScriptDomVisualizer/blob/master/release/Scrip…

This is probably the last contributor that I am going to add to the DacFx deployment contributors project (https://github.com/DacFxDeploymentContributors/Contributors/) for a little while, if anyone else has one they want to contribute please feel free. I have been pretty pleased with how they went but want to make the testing side better. This is an example contributor that is different to all the others in that the previous contributors enumerated the list of steps and either modified one or swapped it with another but this one uses the context object that is passed in to find all changes to stored procedures and then based on the dacpac and deployment database made a decision about whether to fail the deployment or not:

Another day another deployment contributor for the project: https://github.com/DacFxDeploymentContributors/Contributors. This one came about because I was talking to Peter Schott (b|t) over at the deployment contributor gitter room and he has dacpac he wants to deploy to different editions of sql server and enable different options when deploying to enterprise edition. One of the things I found out is that from a contributor, although you have the source and destination models you do not have access to any information about the server other than the version.

I have added my first actual deployment contributor to my deployment contributor project: https://github.com/DacFxDeploymentContributors/Contributors The idea is basically for people to share ideas about writing deployment contributors for SSDT and help each other. If you don’t know what a deployment contributor is then you are missing a real treat. A deployment contributor lets you modify the t-sql that SSDT creates to upgrade a database from one version to the next.

Writing code to generate TSql using the ScriptDom is hard. There is a seemingly bewildering array of objects you can use and where you use different types is unclear, I think this is due to the complexity of the task, it really isn’t simple and dealing with t-sql gets complicated very quickly - to be clear the ScriptDom is a great tool and although is difficult to use is 1 million times better than writing custom parsers / generators for t-sql.

One of the best features of SSDT is deployment contributors. They are so exciting I am going to say it again with more gusto. One of the best features of SSDT is deployment contributors. What these do is let you examine or modify the deployment script that is generated when SSDT compares a project to a database. why is that cool? Please imagine for a minute a scenario where you have used SSDT to generate a deployment script and you have looked at it and scoffed that you could have written a better upgrade script.