4 ms·
I'm planning to do something like this workflow most probably reinventing the wheel along software history: - Every release is already tagged, and merged into m
by danialtz 11y ago
I'm planning to do something like this workflow most probably reinventing the wheel along software history:
- Every release is already tagged, and merged into master (git-flow).
- There is a post-commit hook to backup the database with the tag and time. So I know which database tag is newer.
- Store the encrypted zip on S3, since each developer can deploy.
- Deploy, like cuu508 did.
The problem is with restore. If there is no change in database it is more or less straight forward to download and import the db with the n-1 code tag. But if there are any inserts in database then a migration back should be applied to the latest stand of the database. I can imagine it's going to be a hefty workflow to do.
- mateuszf 11y agoHow about .. have one db with log of events (cqrs style), the other one is transactional and transactions are being performed based on ordered events. When deploying new version - backup the transactional db and keep a pointer to the last event in events db. Keep the events db running. If restoring - restore transactional db backend based on backup and "play back" all events from the events db. The distinction can also be made using one db and backing up / restoring subset of the tables.
- josegonzalez 11y agoSo basically kafka + another layer for database migrations?