Migrations for Cycle Analytics backend
What does this MR do?
Initial migrations and models for the new cycle analytics backend.
More context: https://gitlab.com/gitlab-org/gitlab-ee/issues/12196
What is Cycle Analytics
- TLDR: Find all the Issue or MergeRequest records matching with a date range query (start_event and end_event) = Stage.
- Calculate the duration (end_event_time - start_event_time)
- Extract the median duration
- Extract the list of records relevant to the date range
This change lays the foundation for customizable Cycle Analytics stages. The main reason for the change is to extract the event definitions to separate objects (start_event, end_event) so that it could be easily customized later on. (In EE we'd have about 20 new events)
This MR ensures that we have the right building blocks in place before implementing the customizable stages feature in EE and addresses some of the performance issues regarding to the feature.
To avoid having different implementation in CE and EE, the default cycle analytics stages that we provide (implemented as community contribution) are also implemented with the new structure.
Database Structure Notes
- Gitlab DB guidelines kinda advising against polymorphic associations (we also have a rubocop rule for it, https://docs.gitlab.com/ee/development/polymorphic_associations.html).
- Group and Project specific stage data will be never queried together.
Fields:
-
relative_position: used for the RelativePositioning concern, it's expected to have null values. (column is sorted with NULLS LAST) -
start_event_identifierandend_event_identifier: columns for enums
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry - [-] Documentation created/updated or follow-up review issue created
-
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content