1. Understand
1.1. Database changes do NOT
1.1.1. slow down deployments
1.1.2. lead to downtime
1.2. iconic DB change = schema
1.3. DB change at speed of Software Development lifecycle
2. Pitfalls
2.1. Siloed teams backed by umbrella SLAs
2.1.1. DBA
2.1.2. Devs
2.2. Too many Apps with hard dependency on a shared DB schema
2.3. Lake of DB change mgt tools
3. Implement
3.1. Streamline comm with DBA
3.1.1. Get advise early from DBA expertise
3.1.2. Have DBA aware / ready to apply changes up to prod
3.2. Use BD change mgt tools
3.2.1. What
3.2.1.1. Version control BD schema changes
3.2.1.2. Deploy / roll back DB changes
3.2.1.2.1. according to app version
3.2.1.2.2. consistently over environments: dev, qa, test, prod ...
3.2.1.3. automated / integrated in CICD
3.2.1.3.1. e.g part of the k8s Helm charts
3.2.2. How
3.2.2.1. Schema migrations
3.2.2.1.1. Treat all database schema changes as a migration script
3.2.2.1.2. Order migration script
3.2.2.1.3. Ensure every BD (by env) records applied migrations in a table
3.2.2.1.4. Manage lock to secure concurent changes execution
3.2.2.1.5. Examples
3.2.2.2. Zero downtime DB changes
3.2.2.2.1. Data ghosting
3.2.2.2.2. Decouple database changes / app changes
3.2.2.2.3. Partition and archive data
3.2.2.2.4. Event sourcing architecture
3.2.2.2.5. Use NoSQL DB