How to: zero-downtime database deployments
Great idea to split database deployments in 2 steps.
- expansion scripts
- contraction scripts (cleanup)
The expansion scripts are run at some point prior to upgrading the application and the contraction scripts are run once the system has been upgraded and considered stable. This produces a nice benefit of decoupling database migrations from application deployments. The expansion scripts could be run a day or more in advance of the application deployment at a time that is convenient for database changes. The contraction scripts could be run potentially days after the deployment once everything has been validated with the new release.
Weekly Release Blog #11 – Zero-Downtime Database Deployment
Is the database your center of the architecture? via @unclebobmartin
Do you need a relational SQL store?
Great story from Uncle Bob about his experience with databases and architecture.
We certainly didn’t need a process with a multi-megabyte footprint sitting in memory and burning cycles. (Remember, this was the ‘80s)
Relational databases are huge beasts. Consider other options. Flat files work as well!
The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application.
Ask yourself: Why are we building this? What problem do we solve for our customer?
Here’s what an application should look like. The use cases should be the highest level and most visible architectural entities. The use cases are at the center. Always! Databases and frameworks are details! You don’t have to decide upon them up front. You can push them off until later, once you’ve got all the use cases and business rules figured out, written, and tested.
The database is just a detail that you don’t need to figure out right away.