## Summary This issue is to roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/issues/582586) on production, that is currently behind the `new_addon_lead_endpoint` feature flag. The flag swaps the URL returned by the private helper `Gitlab::SubscriptionPortal::Clients::Rest#addon_trial_lead_endpoint` so that addon-related lead creation (Duo Pro / Duo Enterprise trials) calls the new dedicated CustomersDot endpoint `POST /leads/gitlab_com/addons` instead of the legacy combined `POST /trials/create_addon`. The CustomersDot endpoint shipped in [customers-gitlab-com#15123](https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/15123). The flag uses the `:instance` actor (mirroring the sibling `new_addon_trial_endpoint` flag), so rollout is binary instance-wide on `.com` rather than per-actor percentage. The "Specific rollout on production" section below does not apply. ## Owners - Most appropriate Slack channel to reach out to: `#g_acquisition` - Best individual to reach out to: @anasshahid ## Expectations ### What are we expecting to happen? When the flag is enabled, `CreateAddOnLeadService` posts to `https://customers.gitlab.com/leads/gitlab_com/addons` instead of `https://customers.gitlab.com/trials/create_addon` for the lead-creation step of Duo Pro and Duo Enterprise addon trial signups. Trial-application requests (handled by `ApplyDuoProService` / `ApplyDuoEnterpriseService` and the orthogonal `new_addon_trial_endpoint` flag) are unaffected. ### What can go wrong and how would we detect it? - **CustomersDot endpoint failure**: If the new endpoint returns errors, addon-trial signups would fail at the lead-creation step and users would see the lead-creation failure component rendered by `DuoProController` / `DuoEnterpriseController`. Detect via: - error rate on `POST /leads/gitlab_com/addons` in CustomersDot logs - `duo_pro_lead_creation_failure` and `duo_enterprise_lead_creation_failure` internal events in GitLab.com - `https://dashboards.gitlab.net/d/web-main/web-overview` for the trials request paths - **Routing/auth divergence**: New endpoint requires the same `admin_headers` auth as the legacy endpoint; verify in staging before production rollout. ## Rollout Steps Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command. ### Rollout on non-production environments - Verify the MR with the feature flag is merged to `master` and has been deployed to non-production environments with `/chatops gitlab run auto_deploy status <merge-commit-of-your-feature>` - [x] Enable the feature globally on non-production environments with `/chatops gitlab run feature set new_addon_lead_endpoint true --dev --pre --staging --staging-ref` - [x] Verify that the feature works as expected by submitting a Duo Pro trial signup on `staging-canary` and confirming the lead-creation request hits `/leads/gitlab_com/addons` in CustomersDot logs. - [ ] If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking deployments. ### Specific rollout on production The flag uses the `:instance` actor, so per-project / per-group / per-user rollout is not applicable. Skip directly to the global rollout step below. ### Preparation before global rollout - [x] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable. - [x] Confirm that CustomersDot has the new endpoint live in production (`POST /leads/gitlab_com/addons`). - [x] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. - [x] Notify the `#g_acquisition` channel before global enable. ### Global rollout on production - [x] Enable the feature on production: `/chatops gitlab run feature set new_addon_lead_endpoint true` - [ ] Monitor CustomersDot lead-creation success rate and the `duo_pro_lead_creation_*` / `duo_enterprise_lead_creation_*` events for at least one full business day before considering the rollout complete. ### Release the feature After the feature has been deemed stable, the cleanup should be done as soon as possible. - [ ] Create a merge request to remove the `new_addon_lead_endpoint` feature flag. The MR should: - Remove the `if Feature.enabled?(:new_addon_lead_endpoint, :instance)` branch in `ee/lib/gitlab/subscription_portal/clients/rest.rb#addon_trial_lead_endpoint`, leaving only the new URL `"leads/gitlab_com/addons"`. - Remove the YAML definition `ee/config/feature_flags/gitlab_com_derisk/new_addon_lead_endpoint.yml`. - Update the `#generate_addon_trial_lead` rest_spec back to a single-context form with the new URL. - [ ] Close the [feature issue](https://gitlab.com/gitlab-org/gitlab/-/issues/582586). - [ ] Once the cleanup MR has been deployed to production, clean up the feature flag from all environments: `/chatops gitlab run feature delete new_addon_lead_endpoint --dev --pre --staging --staging-ref --production` - [ ] Close this rollout issue. ## Rollback Steps - [ ] This feature can be disabled on production by running the following Chatops command: ``` /chatops gitlab run feature set new_addon_lead_endpoint false ``` - [ ] Disable the feature flag on non-production environments: ``` /chatops gitlab run feature set new_addon_lead_endpoint false --dev --pre --staging --staging-ref ``` - [ ] Delete feature flag from all environments: ``` /chatops gitlab run feature delete new_addon_lead_endpoint --dev --pre --staging --staging-ref --production ```