1. Agile Database Development and Zero Downtime Deployments
Jeff Reinhard
Agile Database Development and Zero Downtime Deployments

2. About Me Jeff Reinhard 25 years of database development experience
@SQLMajor
Employment Highlights:
Ernst & Young
Internet Security Systems/IBM
AirWatch
WebMD
CheckFree

3. 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

4. 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.

5. 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

6. What is Agile?

7. 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

8. 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

9. What is the Dev DBA? (DataBase Agile)!

10. 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”

11. 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

12. 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

13. Zero Downtime Deployment Time Line

14. Demonstration

15. References
Many theories from: Scott W. Ambler & Pramod J. Sadalage (2006) Refactoring Databases: Evolutionary Database Design Boston, MA: Addison-Wesley

16. Questions and Answers