Repository navigation
Executable tutorial submission: Safe database migrations in CD (tmldjb-cesarah) - #3143
Merged
Merged
Conversation
Collaborator
|
Good, make sure the small CI script is good for the tutorial. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Assignment Proposal
Title
Safe Database Migrations in Continuous Delivery: Migration Linting and the Expand/Contract Pattern
Names and KTH ID
Deadline
Category
Description
We will create an executable tutorial on Killercoda about changing a database schema without breaking a running application. Code changes are easy to roll back, schema changes are not, and during a rolling deploy the old and the new version of an app run against the same database at the same time.
The tutorial starts from a small web service backed by PostgreSQL, with traffic running against it. First, the learner applies a naive migration (renaming a column) with dbmate and watches the old version of the service start failing. Then they add squawk, a linter for PostgreSQL migrations, as a check in a small CI script, and see it block the same migration before it reaches the database. Finally, they redo the change with the expand/contract pattern: add the new column with a trigger that keeps both columns in sync, backfill it, roll out the new version, and only drop the old one once nothing reads it anymore. A last step shows the difference between a normal index build, which blocks writes, and
CREATE INDEX CONCURRENTLY.Everything runs in the browser with pinned versions and no accounts. Each step has a check script, and the tutorial includes an architecture diagram and a reflection on when this approach is worth the extra steps and when it is not.
Relevance
Continuous delivery assumes that any commit can be deployed safely, but database migrations are often the part that still needs a maintenance window. Zero-downtime deploys require the schema to work with two versions of the application at once, which is the same problem canary and blue-green releases deal with. Checking migrations automatically in CI is a shift-left practice that turns knowledge about locks and breaking changes into a repeatable gate.
Link to tutorial