Always use the refactoring operations when renaming objects. If
you don’t do so, you risk causing errors in your deployments.
Use continuous integration (CI) to verify that your SSDT projects
build and deploy successfully. SSDT projects are MSBuild compliant
and therefore lend themselves very well to use in CI setups.
In many multi-developer project teams I’ve worked in, those developers shared the same central development server, which led to problems when different developers needed to use the same resources.
SSDT supports, and indeed promotes, the use of “sandboxes” where
each developer has his or her own development database, usually on
his or her own workstation. I highly recommend this as a method of
development.
Build and deployment of SSDT projects can be done from the command line (via msbuild.exe and sqlpackage.exe, respectively). Thus
I recommend that you write a short batch file (in either DOS or
PowerShell) that can automate these tasks for you. This enables the
developers to carry on developing instead of locking up Visual Studio
while a build/deployment is occurring. That script can also be shared
throughout the team, thereby ensuring that each team member is
deploying in the same consistent manner.
More Yet to Explore
Although I’ve I covered what I believe to be the most important features
of SSDT, many more features remain for you to explore. For example,
the SQL Server 2012 Data-Tier Application Framework (incorporating
.dacpac files), sandbox development using LocalDB, F5 deployment
to LocalDB, static code analysis, MSBuild support, connections to
SQL Server instances within SQL Server Object Explorer, pre- and
post-deployment scripts, and more are all worthy of inclusion here,
but for reasons of brevity will have to be saved for another time. ■
