Designs to have iids scoped to Project
For the direction of Design Management, we want to be able to use designs in more places. Right now, that is hard to achieve because our designs are scoped to a GitLab Issue instead of a project. This means the URL is held to the project and it does not have a unique identifier.
As a part of our re-architecture effort, one of the first steps is to assign iids to each design object. This will eventually allow us to have unique URLs (just like MRs and Issues) and more sharing of designs.
We would like designs to have
iids scoped to the
Project (like how issues and MRs do).
This will allow us to link to designs using their
iid in Gitlab-flavored markdown, and also to display the designs at a URI like
Engineering MR Breakdown
@lulalala: Would it be preferable to reserve enough iid numbers for existing designs, so after design iids order still represent chronological order?
- 1 MR (add table and ensure iids for new designs)
- 1 MR (background migration for old designs)
@.luke: The requirements for a data migration to backfill data can be complex (previous experience)
- iid database migration
Design(using backfill: true)
- data migration to backfill iids
- remove backfill: true from
@toupeira: We have existing functionality to handle the backfilling for us, and also a similar MR to use as a basis.
- 1 MR to introduce IIDs
- 1 MR to add a data migration to backfill existing designs
- 1 MR (at least 1 minor release later) to disable backfilling
This needs to go out in two, possibly three parts: one for the migration and new iid allocation, a background migration to backfill the old designs, and then maybe a third for updates to scopes/finders
- migration/data model
- service level operations
- Reuse existing shared examples.
- Test the data migration.
- model specs
- data migration specs
- Need to test that we can assign and search for designs by iids