Ticket created by ~jad7 on ~olly/yoyo
What I have to do: Application code and DB code should be separated and have a different release process. The application should know about the exact version of DB schema to apply migrations.
I have DB schema version 1 and the app expects DB version 1. I want to add a new feature to the app and change the DB schema. I do:
- Prepare a new DB migration version 2, release a new DB artifact (V2)
- Implement a new feature in the app, set an expected DB version 2
Rollout application: Push the new version of the app with the latest version of the DB artifact. The application knows that it needs DB V2; check the current DB version (1); apply migrations list till V2 from the latest DB schema artifact.
Rollback application (new version): Push the prev (v1) version of the app with the latest version of the DB artifact. The application knows that it needs DB V1; check the current DB version (2); rollback migrations (needed, current] ( means (v1, v2] from the latest DB schema artifact. (I always need the latest version of DB artifact!)
What I want to do: I want to have the ability to store migrations with the application source code. When yoyo applies migrations it should also store rollbacks in DB. And when I want to rollback migration from V2 to V1, it will apply rollback from the DB.
I have the app code with DB migrations in the same repo. I want to add a new feature to the app and change the DB schema. I do:
- Prepare a new DB migration version 2
- Implement a new feature in the app (DB and app changes in the same Pull-request)
Rollout application (new version): The application has a full list of migrations to apply (till V2). Applies it on startup.
Rollback application: The application has migrations till V1. But current DB version - V2. There are no v2 migrations and rollbacks with the app. Yoyo can fetch all rollbacks from DB till V1 and apply them to have a consistent DB version for the app.