Best Practices for Multi-Environment

Database Development in Visual Studio

Erick Ellis
Principal PM Manager
Microsoft

Lonny Bastien
Senior Program Manager
Microsoft

Approach
3 demos & light slideware
In market Microsoft SQL relational platform
Visual Studio integrated experience
Database projects
Advanced but not obscure

Multi-Environment
Manage object types by security role
Users and logins not managed by the development team

Architect for per environment specializations

The customer is always right and it turns out their requirements and workloads are
different.

Establish coding standards across a development

group
Your way its not always the right way

Manage object types by security role

Origin Story

Users and logins not managed by the development team

Background
Relatively rigid declarative model what is whole database?
Disabled DropObjectsNotInSource has significant side effects
Select features had custom deploy options partition schemes, index
options, etc
User, logins have no custom deploy options

#1 MSConnect vote is to address this scenario

emo

Manage object types

by security role

Origin Story

Architect for per environment

specializations
The customer is always right and it turns out their requirements
and workloads are different.

Leverage composite projects instead of unwieldy

post-deployment scripts
Declarative anti-pattern how many rebuilds do
you want?
We know your business best?

Multiple Environments

Common core-schema with customizations per deployment

Common for Dev, Test and Prod deployments
Common for ISV deployments

How do you define different indexes?

How do you define different permissions & logins?
How do you run different pre and post
deployment scripts?

Single Project
Common Core
Company
A
Visual Studio

Company
B

Composite Projects

Company
A

(Same DB Same Server)

CompanyA
Common Core

Deploy
Reference

Visual Studio

Company
B

CompanyB

User

Deploy
Reference

emo

Architect for per

environment
specializations

Origin Story

Establish coding standards across a

development group
Your way its not always the right way

Organizations benefit from consistency

Code reviews dont catch everything
Catch errors upstream closer to the developer,
sooner in the process
Built in SCA rules are limited
Database unit testing provides another layer of
validation behavior

emo

Establish coding
standards across a
development group

Advanced approaches
Approach

Best uses

Language

Reuse

Pre-deployment scripts
Post-deployment
scripts

Project data
Advanced per environment
configuration

T-SQL

Source

Advanced deployment
options

When Dev and DBA roles are

separate

Publish

Source

SCA Rules

Enforce best practices and business

policies

C#

Install dll

DB unit testing

Enforce functional behavior

T-SQL

Source

Deployment
contributors

Support online- options

Advanced deploy scenarios

C#

Install dll

Composite projects

Multi-env (Dev,stage,prod)
ISV pattern

T-SQL

Source

SQLCMD variables

Per environment configuration

T-SQL

Source

Best Practices for Multi-Environment

Database Development in Visual
Studio

THANK YOU
Lonny Bastien
LonnyB@microsoft.com

Erick Ellis
ErickE@microsoft.com

Ssdt forum/blog msdn.microsoft.com/data/tools

Deployment contributor/ SCA samples Dacsamples.codeplex.com
SCA rules - Tsqlsmells.codeplex.com
Folder - C:\Program Files (x86)\Microsoft Visual Studio