A teams maturity shows in its choice of tools. I have seen quite a few different development teams in wildly different environments and the single fact that really stands out is that you can tell how good a team is by the tools that they use. It isn’t always the specific choice of which tools they use, although that can be important, it is the fact that they evaluate and chose to either use or ignore new tools.

What is this? Well if you read the name aloud “SQL Server Continuous Deployment in a box” then, if I have done my work correctly choosing the title for the blog, give a hint :) what is the big idea? There is really some great tooling for SQL Server - second to none really when it comes to RDBMS’s and setting up Continuous Deployment pipelines is actually pretty simple once you know which parts to plug together.

If you have ever tried to debug a program that used the TSql Script Dom to parse some T-SQL you will know that the process is extremely slow and this is due to the volume of NoViableAltExceptions (and others) that are thrown and then caught. Because these are first chance exceptions they are being handled and it is the way that the script dom interacts with Antlr and the Lexer that they use.

Following on from yesterdays blog I was wondering about the comparison of objects that were the same and how the IgnoreWhitespace, IgnoreComments, IgnoreKeywordCasing and IgnoreSemiColonsBetweenStatements flags affected the comparison. To be fair I was only interested in IgnoreWhitespace but actually it turns out that those four are very closely related. When the deploy happens, where a script in the source and target are compared the process is: 1. Loads of things we will skip 2.

Publishing dacpac’s is a little bit of a pain when you have multiple databases, it can easily start to take minutes to hours to deploy changes depending on how many databases and the size of those databases. I wanted to understand more about the publish process and what we can do to speed it up as much as possible so I did some digging and this is a randomish post about how it all works and what we can do to make it faster.

I did a talk at the london .net meetup if you want to get an overview of what SSDT is and how to get started then I would recommend it: https://skillsmatter.com/skillscasts/9274-londondot-net-january-meetup This was aimed at .net developers rather than DBA’s so there isn’t much talk about “why you should use source control” etc as everyone in the room used source control already :)

I was talking to someone at a meetup recently who was really keen on doing continuous deployment for their database but they had a number of issues, the main was that because management wasn’t sold on the idea and the DBA’s had complete control to push back on all and every idea he had - there was no way he could deploy continuously. The accepted route for devops is management buy-in, if you do not have management buy-in then you can’t do devops.

There have been a couple of fixes in SQLCover this week, kindly submitted by John Mclusky (https://github.com/jmclusky): Code coverage not reported correctly for CTEs at the end of a stored procedure if the ‘with’ is immediately preceded with a semicolon and DeclareTableVariableStatement statements cannot be covered, so report falsely as missing coverage I have also changed where the releases can be downloaded from to use the github releases: https://github.com/GoEddie/SQLCover/releases The previous version is still available but I would recommend the latest version.

In this post I will talk about the in-built refactoring support in SSDT – the language is slightly different from my normal style as originally it was going to be published else but rest assured it is written by myself What is refactoring? In programming , the term ‘refactoring’ essentially means taking some code and improving it without adding features and without breaking the code. When we refactor code we ideally want to make small improvements over time, using an IDE that automates as many of the tasks as possible for us.

The ideal is to make a change and see that change deployed to production, in a perfect world we would be told to work on something, write the code + tests, deploy to a test environment, prove it works and deploy - this is the cycle time and the faster you can get this the easier many things become. The cycle time is easy to measure - it is the time the ticket arrives in the backlog to the time it moves to the done column, if your issue tracking system can’t tell you this easily then use something else!