This epic captures the feature delivery roadmap for database migrations and background job enablement in Theseus. ## Outcomes * Modular Features on Theseus have a clear and consistent framework for running database migrations * Modular Features on Theseus have a clear framework for running background jobs such as long-running database backfills ## Context Database migrations represent a core responsibility of application developers maintaining and extending modular features on the Theseus platform. It is imperative that we provide a centralised database migration framework that is congruent with not only our existing tooling, but with our plans our how we expect consumers of these modular features to walk through installation and upgrade flows. ### Sub-Problems We'd Like to Solve Note: This is a very rough initial list - if you are aware of additional problems with our current systems, please do add them below or comment on this epic to help provide clarity. #### How Do We Make the Upgrade Process Smoother? We know that dedicated faces a substantial number of incidents and issues when it comes to upgrading from N.M to N.M+1. This can be due to a number of reasons: * The shape of the data in dedicated could be subtly different from dotcom and migrations find these sore little edge cases. * We don't have great automation for running background jobs that do things like backfilling database tables in a lock-step fashion to their corresponding migrations. * Database migrations in production may need long-running background jobs to successfully execute prior to a migration landing. ## Related Resources: * Andrew has some prior art here: https://gitlab.com/gitlab-org/gitlab/-/work_items/607492 * Go POC - https://gitlab.com/gitlab-org/quality/go-service-template/-/merge_requests/53 * My wishlist - https://gitlab.com/gitlab-org/quality/go-service-template/-/work_items/4 ## Roadmap The goal for this project is "how do we build the database migration functionality into Theseus in an incremental fashion" - it's with this framing that we'll be approaching the delivery. --- # MVP - Unblocking Orbit + AR I'm going to split these two milestones out into 2 separate epics - they are substantial enough in their own right that we should be giving them both adequate space. ## Milestone 1 - Providing Basic Migration Functionality **Use case:** As a modular feature team engineer, I can define a migration file, and the deployment + installation process will ensure that this migration is executed and the database schema will be modified. **Requirements:** * I am able to see the results of the migration and explicitly understand if that migration has passed/failed * I am able to run down migrations if a rollback to a previous version of my service is necessary **Notes:** * Providing the mechanism through which team members can test both up and down migrations will be essential. We want to help facilitate a smooth upgrade/downgrade flow where possible. ## Milestone 2 - Background Job Framework in Theseus Established **Use case:** As a modular feature team engineer, I can define a background job within Theseus, and it will be executed/instantiated on next deploy. **Requirements:** * I am able to see the ongoing execution of these background jobs through various observability channels * I am able to stop background jobs quickly in production to mitigate potential incidents --- # Post MVP The initial focus should be on providing the functionality that meets the above use-cases. That being said, we do need to look ahead and ensure that we're establishing a foundation that we can extend over time and provide additional incremental value.