Agile Database Development and Zero Downtime Deployments Jeff Reinhard Agile Database Development and Zero Downtime Deployments
About Me Jeff Reinhard 25 years of database development experience @SQLMajor Employment Highlights: Ernst & Young Internet Security Systems/IBM AirWatch WebMD CheckFree
What is the problem? Front end development has gone agile Pace of business demands is brisk Waterfall process just no longer works Companies no longer tolerate “12 hour” downtimes No more waiting 6+ months for next release
What happens on Deployment Day? timestamp is the synonym for the rowversion data type and is subject to the behavior of data type synonyms. In DDL statements, use rowversion instead of timestamp wherever possible. Also, Big indexes.
What changes are needed? Add new features while maintaining backward compatibility Enable the database to support multiple versions of the application This allows deploying changes in advance of version switch over WITHOUT an outage Development approach in step with agile
What is Agile?
What is this agile thingy? Just to visit briefly, some of the key concepts Done in small iterations (sprints), 1-4 weeks duration, usually 2 or 3 Working software after every sprint Any sprint could be deployed to production
How to become database agile Complete working code every sprint Database code may be ready ahead of UI code to use it Some changes may need to support transition periods Test Driven Development will help increase quality
What is the Dev DBA? (DataBase Agile)!
How to do Zero Downtime Deployments All changes are made in small units of work to unsure that each change is: Uniquely identified Easily refactored or changed as needed only affecting a small amount of work Transition periods are properly supported The period of supporting both states, and The update to terminate the support of the starting version Test driven development Stored Procedure versioning Strict adherence to the refactoring type methodologies Most adds and drops don’t require an actual “transition period”
Refactoring Types By strictly following the methodology of each refactoring type, agile and zero downtime deployments are possible. Here are some of the at least 35 types: Drop Column Drop View Drop Table Merge Columns Merge Tables Move Column Rename Column Rename Table Rename View Replace Column Split Column Split Table Add Lookup Table Drop Default value Drop FK constraint Add Calculated Column Add Surrogate Key
Some refactoring types in detail Move Column Details: Original schema, Column in Table A Change to move to Table B During Transition period Leave column in Table A Add Column in Table B Add trigger in Table A to update table B Add trigger in Table B to update table A Stored Procedure versioning, old uses Table A, new uses Table B After Transition Period Drop column from Table A Drop trigger from Table and A & B Drop old version procedures Split Column Details: Original schema, Name Column Change to FirstName and LastName During Transition period Leave Name column Add Column FirstName and LastName Add trigger to update FirstName and LastName from Name Stored Procedure versioning, old uses name, new uses FirstName and LastName After Transition Period Drop Name column Drop trigger Drop old version procedures
Zero Downtime Deployment Time Line
Demonstration
References Many theories from: Scott W. Ambler & Pramod J. Sadalage (2006) Refactoring Databases: Evolutionary Database Design Boston, MA: Addison-Wesley
Questions and Answers