Release post item: Duo Agent Platform for free users

Team members for review and approval: Engineer(s): @engineers | Product Marketing: @PMM | Tech Writer: @TW | Product Designer(s): @ProductDesigners

Engineering Manager to merge when the feature is deployed and enabled: @EM

Important note on tier labels: Until further notice, due to change management reasons, please leverage label core to indicate 'free' tier in all code and templates.

Please review the guidelines for content block creation at https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#content-blocks.

Links

• Feature Issue (required): gitlab-org#20165
• Pricing theme MR (required for primary features in Premium or Ultimate only): N/A (core/free tier)
• Feature MR (optional):
• Feature Flag Issue (optional): https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/16455

Key dates

• By Monday of the week the milestone ends: PMs should draft/submit for review ALL release post item content.
• By Thursday, the day before the milestone ends: All required TW reviews and revisions should be done.
• By the Friday the milestone ends: Release post items need to be marked with the Ready label to be merged.

Getting ready for merge

Reminder: Make sure any feature flags have been enabled or removed!

Once all content is reviewed and complete, add the Ready label and set the Engineering Manager (EM) as the Assignee.

Review

• (Required) Tech Writer reviewed and approved
• (Recommended) PMM reviewed and approved
• (Optional) Product Designer reviewed and approved
• (Optional) Group Manager or Director reviewed and approved
• PM adds Ready label and sets EM as Assignee for merge

EM release post item checklist

Expand for Details

• Set at least one code MR as a blocker for this MR by going to Edit > Merge request dependencies. Setting a code blocker improves clarity, and prevents premature merge. If no feature MR exists, go to the most relevant issue and click "Create merge request" to create an empty merge request. Use the feature flag rollout issue if one exists.
• When this MR is labeled as Ready and assigned to you:
  • Confirm the feature is in the release and note the following:
    • Be aware that merging code to master "does not guarantee that the feature will be in the release" (source).
    • If in doubt, you should confirm the feature commits are in the x-y-stable-ee branch (for example, 13-12-stable-ee).
    • Changes merged into master 1+ day prior to x-y-stable-ee branch being created will likely be included in the release and release post for those features can be merged, unless there are incident blocking pipelines or a broken master.
    • You can also use the chatops command /chatops run release check [MR_URL] [RELEASE] to check if the MR will be included in the release.
    • Note: for any MRs merged close to the cutoff date, the results are not definitive until the stable branch is cut. If the code is not in the release or the deadline has passed, update this merge request's milestone accordingly and leave this unchecked.
  • If the feature has a feature flag, verify it is enabled by default.
  • If before 11:59PM PT on the Friday the milestone ends, merge this merge request to the master branch. If after that time, but you believe this should be merged late, follow the process for late additions and be sure to inform the release post manager.