### Problem There are three types of PushRules: 1. `Global push rule` (only one per instance, has `organization_id=1`) 2. `Group push rule` (defined per group, see `namespaces.push_rule_id`) 3. `Project push rule` (created for each new project, [uses a snapshot from `Global` or `Group` PushRule](https://gitlab.com/gitlab-org/gitlab/-/blob/38064b0714b5cc2bdb14a530e4482550e0ecf63c/ee/app/services/ee/projects/create_service.rb#L137-149)) All push rules are stored in the same database table that complicates the creation of the sharding key for them. In this case, what do you think about extracting `group_push_rules` and `organization_push_rules` from `push_rules` idea? If we have more time, then I see a reason to provide a clear separation between different push rules types rather than try to store them in the same table as we do now. ## High-level proposal 1. Restructure push rules to store each push rule type in a separate table: * `group_push_rules` - for Group push rules (sharding_key `group_id`) * `organization_push_rules` - for Organization push rules (sharding_key `organization_id`) * `push_rules` - for Project push rules (sharding_key `project_id`) 2. Migrate existing Group and Organization push rules from `push_rules` into `group_push_rules` and `organization_push_rules` accordingly. 3. Remove Group and Organization push rule records from push_rules, effectively converting push_rules into a Project push rules table. ## Implementation plan 1. [[Phase 1] Restructure `push_rules`: data migration](https://gitlab.com/groups/gitlab-org/-/epics/16894) 2. [[Phase 2] Use the new data structure for push rules management](https://gitlab.com/groups/gitlab-org/-/epics/16895)