SQL Server Pro - May 2013

º Preview: a textual description of what the Publish opera-
tion is going to do
º Script: the script that SSDT generates transparently, as
explained previously
º Results: the output from running the script
In my opinion, declarative database development is the killer fea-
ture of SDDT. Put more simply, declarative database development is
the reason that I use SSDT. This isn’t just a developer crush, either.
The DevOps guys on my current project were initially reticent about
letting a tool govern our database deployments. But after carrying
out numerous deployments to our production environment using
this technique in the past couple of months, they’ve been won over
and are now mandating that all development projects move to using
SSDT. In fact, when asked for a quote for this article, the head of our
DevOps team, Joe Pollock, had this to say:
Having been used to database releases being packaged as a
set of scripts, variously doing create and alter DDL statements,
suddenly being handed an SSDT release was an uncomfort-
able change. Letting the release itself determine the schema
changes required based on the target database? This required
a lot of trust in the process, even though historically the hand-
crafted scripts were prone to mistakes, were labor-intensive
to run, and required before and after compares to have confi-
dence in them.

But this much simpler method of defining the schema once using create statements and then trusting SSDT to do what it needs to on the target makes everybody’s job easier. Harnessing the power of this tool has reduced the complexity of managing releases, both in packaging and deploying them, and I am now a huge fan of this method.