It takes a leap of faith to start trusting SSDT in this manner, but with
the proper precautions in place (see my tips a bit later in the article),
it can be a leap worth taking.
Figure 2
Sample Refactor Log
Developer Productivity
Improving developer productivity is a real focus for SSDT. Let’s look
at some of the significant features in this area.
Refactoring. Refactoring code can generally be described as altering how a code module executes without changing what it actually
does. SSDT provides support for such changes.
Renaming an object (such as a table) or moving it to a different
schema will, ordinarily, break any code modules (e.g., stored procedures, views, triggers, user-defined functions) that reference that
object. This is an area where SSDT refactoring is intended to help.
Using SSDT refactoring will not only affect the rename/move operation, but it will also alter any referencing code modules accordingly.
Such refactoring operations are commonplace in other development tools. However, the very nature of
a database means that SSDT refactoring
is a little different. Not only does SSDT
change the object and referencing code,
it also records the change in a file called
the refactor log, which exists as an artifact of the project, as shown in Figure 2.
Consider the example of a column being renamed. The Publish
operation needs to know that it should issue a call to sp_rename
rather than causing data loss by dropping the column with the old
name and creating a new column with the new name. This is the
purpose of the refactor log: to record the fact that a rename has
taken place.
Go to definition. This is a code-navigation feature that has long
existed in Visual Studio for .NET language development and is a welcome addition to SSDT. Simply placing your cursor on an object (say,
