• Enable control over database development • Increase speed of response to change • Keep a versioned “history” of database states • Greater reliability of the release process • Remove/reduce human intervention in the release process From (Re)Learn and forget it to Improve and forget it
description • First step in your database deployment pipeline • Traceability through change history • SQL as documentation • Shared code-base and shared process • Enforceable standards to reduce conflicts • Fundamental resource: SQL script
vs State • State based solutions • Script represents the current database state • Your source of truth is how the database should be • Migrations based solutions • Script represents a migration • Migration represents how to transition to the next database version • Your source of truth is how the database should change SQL Source Control
validation • Integrate and validate changes • Small batches • Unit, Integration, Acceptance tests • What tests should be done? • Before, during and after the deployment? • What happens if tests breaks? • Depends on what was broken, when was broken • Manual intervention, automation? • Rollback, roll front?
implementation • Delivering the change(s) in the target environment • Build once, deploy any (promote) • Deployment considerations • Time to recover • Small batches – low risk • Downtime • Affected applications
point did it fail? • What changed? • Do I have partially updated data? • Do I have partially objects changed? • How can I go back to the last known state? • Rollback database objects • Rollback the full database • Rollback scripts (or should I call roll front?) • Very fast • Do not make mistakes • Do I have partially objects changed? • Backups (before deploy) • Safer method • Slower deployments (database is down during deploy) • Keep databases small • Avoid share databases between applications
Relational database-as-a service • Keep your databases small and independent • You pay for each database • ARM templates • “Infrastructure” orchestration
• DevOps as a Contract – collaboration and communication mechanism for change management • Should be reflected in your deployment pipeline • The better/clearer your pipeline, the less you need to document (your code is your documentation) • Everything is negotiable in the contract, except its application