demo company a company b user
TRANSCRIPT
Best Practices for Multi-Environment Database Development in Visual Studio
Erick EllisPrincipal PM ManagerMicrosoft
Lonny BastienSenior Program ManagerMicrosoft
Approach3 demos & light slidewareIn market Microsoft SQL relational platformVisual Studio integrated experienceDatabase projects
Advanced but not obscure
“Multi-Environment”Manage object types by security roleUsers and logins not managed by the development team
Architect for per environment specializationsThe customer is always right … and it turns out their requirements and workloads are different.
Establish coding standards across a development groupYour way … it’s not always the right way
Manage object types by security roleUsers and logins not managed by the development team
BackgroundRelatively rigid declarative model – what is “whole” database? Disabled DropObjectsNotInSource has significant side effectsSelect features had custom deploy options – partition schemes, index options, etcUser, logins have no custom deploy options
#1 MSConnect vote is to address this scenario
Ori
gin
Sto
ry
Manage object types by security role
Dem
o
Ori
gin
Sto
ryArchitect for per environment specializationsThe customer is always right … and it turns out their requirements and workloads are different.
Leverage composite projects instead of unwieldy post-deployment scriptsDeclarative anti-pattern – how many rebuilds do you want?
We know your business best?
Multiple EnvironmentsCommon core-schema with customizations per deployment
Common for Dev, Test and Prod deploymentsCommon 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
Table
Index
User
Login
Common Core
Visual Studio
Company A
Company B
Composite Projects (Same DB Same Server)
Table
Index
Login
Common Core
Visual Studio
Reference
Reference
User
Deploy
Index
Login
UserUser
TableTable
Index
Login
Index
Login
Deploy
CompanyA
CompanyB
CompanyA
CompanyB
Architect for per environment specializations
Dem
o
Establish coding standards across a development groupYour way … it’s not always the right way
Organizations benefit from consistencyCode reviews don’t catch everythingCatch errors “upstream” closer to the developer, sooner in the processBuilt in SCA rules are limitedDatabase unit testing provides another layer of validation – behavior
Ori
gin
Sto
ry
Establish coding standards across a development group
Dem
o
Advanced approachesApproach Best uses Language Reuse
Pre-deployment scriptsPost-deployment scripts
Project dataAdvanced 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- optionsAdvanced 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
Lonny [email protected]
Erick [email protected]
THANK YOU
Best Practices for Multi-Environment Database Development in Visual Studio
Ssdt forum/blog – msdn.microsoft.com/data/toolsDeployment contributor/ SCA samples – Dacsamples.codeplex.com SCA rules - Tsqlsmells.codeplex.comFolder - C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120\Extensions