## Summary This issue tracks the limited production rollout of `fetch_contributions_data_from_new_tables` for `gitlab-org` only. Related work items: - Implementation work item: `https://gitlab.com/gitlab-org/analytics-section/siphon/-/work_items/96` - Rollout work item: `https://gitlab.com/gitlab-org/gitlab/-/work_items/601099` This flag switches contribution reads from the old tables to the new tables, with no expected user-facing behavior change. The initial rollout target is the `gitlab-org` group only. ## Owners - Team: Analytics Section / Data Engineering - Most appropriate Slack channel to reach out to: `#g_plan_optimize` - DRI: Felipe Cardozo ## Expectations ### What are we expecting to happen? - No user-facing behavior change. - Contribution-backed GraphQL results for `gitlab-org` should remain functionally equivalent before and after enabling the flag. - The implementation should switch from the old contributions table path to the new contributions table path, including the organization-aware traversal logic required by the implementation work item. ### What can go wrong and how would we detect it? - Incorrect contributor counts or per-user contribution metrics - Missing users or mismatched event totals in contribution analytics - Performance regressions or timeouts on contribution-backed GraphQL endpoints - Data parity issues caused by switching reads from old contribution tables to new contribution tables ### What can we monitor to detect problems with this? - Before/after GraphQL comparisons against `gitlab-org` - Kibana / Sentry for GraphQL timeouts and resolver errors on contribution analytics paths - Dashboard and application error rates after enabling the flag for `gitlab-org` ## Rollout Steps ### Rollout on non-production environments - [ ] Ensure the MR that changes the flag definition / rollout logic has been merged and deployed to non-production: - `/chatops run auto_deploy status <merge commit SHA>` - [ ] Enable on non-production environments: - `/chatops run feature set fetch_contributions_data_from_new_tables true --dev --pre --staging --staging-ref` - [ ] Run the GraphQL parity checks on staging for `gitlab-org` - [ ] Verify there are no GraphQL errors, unexpected count changes, or regressions ### Specific rollout on production For visibility, all ChatOps commands that target production should be executed in `#production`. - [ ] Ensure the rollout MR has been deployed to production and canary: - `/chatops run auto_deploy status <merge commit SHA>` - [ ] Capture the before state for `gitlab-org` using the GraphQL queries below - [ ] Enable the flag only for `gitlab-org`: - `/chatops run feature set --group=gitlab-org fetch_contributions_data_from_new_tables true` - [ ] Verify the flag state: - `/chatops run feature get fetch_contributions_data_from_new_tables` - [ ] Capture the after state for `gitlab-org` using the same GraphQL queries - [ ] Compare results and confirm parity - [ ] Monitor errors and performance for at least 15 to 30 minutes after enablement ### Preparation before broader rollout This issue is for a limited-risk production rollout on `gitlab-org` only. A broader rollout should happen only after parity and stability are confirmed. - [ ] Set the milestone for this rollout issue - [ ] Confirm whether a separate change management issue is required - [ ] Ensure someone from development is available for at least 2 hours after the production toggle - [ ] Leave a comment on the implementation work item with the planned production rollout time - [ ] Ensure this rollout plan has been reviewed by another developer familiar with the contribution analytics domain ### Global rollout on production Not part of this issue. ## Validation Queries ### Query 1: contributors count ```graphql query GroupContributorsCount($fullPath: ID!, $start: Date!, $end: Date!) { group(fullPath: $fullPath) { valueStreamDashboardUsageOverview( identifier: CONTRIBUTORS timeframe: { start: $start, end: $end } ) { count } } } ``` Variables: ```json { "fullPath": "gitlab-org", "start": "2026-05-01", "end": "2026-05-25" } ``` ### Query 2: Duo chat contributors ```graphql query GroupAiMetricsDuoContributors($fullPath: ID!, $start: Date!, $end: Date!) { group(fullPath: $fullPath) { aiMetrics(startDate: $start, endDate: $end) { duoChatContributorsCount } } } ``` variables: ``` json { "fullPath": "gitlab-org", "start": "2026-04-01", "end": "2026-04-30" } ``` ### Query 3: contribution analytics per user ```graphql query GroupContributionAnalyticsComparison( $fullPath: ID! $from: ISO8601Date! $to: ISO8601Date! $first: Int! $after: String ) { group(fullPath: $fullPath) { contributions(from: $from, to: $to, first: $first, after: $after) { nodes { user { id username name webUrl } totalEvents issuesCreated issuesClosed mergeRequestsCreated mergeRequestsMerged mergeRequestsApproved mergeRequestsClosed repoPushed } pageInfo { endCursor hasNextPage } } } } ``` Variables: ```json { "fullPath": "gitlab-org", "from": "2026-05-01", "to": "2026-05-25", "first": 100, "after": null } ``` ## Rollback Steps - [ ] Disable on production for `gitlab-org`: - `/chatops run feature set --group=gitlab-org fetch_contributions_data_from_new_tables false` - [ ] Verify the flag state: - `/chatops run feature get fetch_contributions_data_from_new_tables` - [ ] Disable on non-production environments: - `/chatops run feature set fetch_contributions_data_from_new_tables false --dev --pre --staging --staging-ref` ## Release / Cleanup This is an implementation-only, de-risking flag. After parity is confirmed and the new table path is stable: - [ ] Create an MR to remove `fetch_contributions_data_from_new_tables` - [ ] Remove all references to the feature flag from the codebase - [ ] Remove the YAML definition for the feature flag - [ ] Ensure the cleanup MR is included in the release package - [ ] Clean up the feature flag from all environments: - `/chatops run feature delete fetch_contributions_data_from_new_tables --dev --pre --staging --staging-ref --production`