Skip to content

Release 18.6

First steps

[GPRD] [2025-10-24 to 2025-10-28] - Upgrade PostgreSQL to PG17 - sec database: gitlab-com/gl-infra/production#20439 (closed)

  • CR starts at 2025-10-24 16:00
  • On 2025-10-24 15:00 UTC,
    • Lock gprd-cny environment - /chatops run deploy lock gprd-cny
  • Unlock gprd-cny once we get the green light - /chatops run deploy unlock gprd-cny

[GPRD] [tbc] - Upgrade PostgreSQL to PG17 - main database: gitlab-com/gl-infra/production#20440

  • CR starts at 2025-10-31 16:00
  • On 2025-10-31 15:00 UTC,
    • Lock gprd-cny environment - /chatops run deploy lock gprd-cny
    • Unlock gprd-cny once we get the green light - /chatops run deploy unlock gprd-cny

Optional: First Staging Rollback Practice

Note

If the release manager is proficient with the rollback procedure or already performed at least one rollback during the current rotation, they can skip the practice.

Date to be Completed: 2025-10-30

  • @madelacruz @akozin-ext
  • Perform Staging Rollback Practice
  • Set Due date for this issue to the date of the next practice session. If none, set it to the release date.

2025-10-23: Test Rails 7.2 Rollout (gstg-cny, g... (gitlab-com/gl-infra/production#20789 - closed)

  • @acafefebrissy

Optional: Second Staging Rollback Practice

Note

If the release manager is proficient with the rollback procedure or already performed at least one rollback during the current rotation, they can skip the practice.

Date to be Completed: 2025-11-06

Hot patching production practice

Date to be Completed: 2025-11-13

The work here is to be done by the next release managers. Please tag them to the item below.

  • @rpereira2
  • Perform hot patching Practice
  • Hot Patching practice is documented: <link to comment>
  • Set Due date for this issue to the date of the next practice session. If none, set it to the release date.

Hard PCL 1: 2025-11-11 09:00-10:30 UTC

At 09:00 UTC

Lock gprd-cny to make sure no deployments make it there and further.

  • /chatops run auto_deploy pause
  • /chatops run deploy lock gprd-cny

At 10:30 UTC

Unlock gprd-cny.

  • /chatops run auto_deploy unpause
  • /chatops run deploy unlock gprd-cny

Hard PCL 2: 2025-11-13 09:00-10:30 UTC

At 09:00 UTC

Lock gprd-cny to make sure no deployments make it there and further.

  • /chatops run auto_deploy pause
  • /chatops run deploy lock gprd-cny

At 10:30 UTC

Unlock gprd-cny.

  • /chatops run auto_deploy unpause
  • /chatops run deploy unlock gprd-cny

Up until Tuesday, 2025-11-18

  • Ensure any deploys that do not make it to canary are investigated. Disable canary if necessary.
  • Push any successful deploy to canary into production after some time has passed (preferably 1h).
  • Should any deployment blockers prevent automatic promotions to production, this requires approval by the SRE On-Call.
    1. Ask for permission to promote the release in #production - provide the necessary context to the Engineer
    2. If permission is granted, set the OVERRIDE_PRODUCTION_CHECKS_REASON as a variable in the manual promote job. The value of the variable should be the reason why production checks are being overridden. See gitlab-com-deployer.md#skipping-production-promotion-checks for more info.
    3. This will post a comment into this issue and begin the deployment
    4. Ask the SRE On-Call to respond to the comment with their approval for auditing purposes

Release Preparation

Initial RC: Tuesday, 2025-11-18

  • Make sure to execute the post-deploy migration pipeline to ensure that all post-deploy migrations have been executed:

    /chatops run post_deploy_migrations execute

  • If there was an Internal release after the last patch release and it includes a security fix:

    • Select a commit before the internal release merge request for the next tagging step:
    • Link the Internal release issue:

  • Start the monthly_release_initial_rc:start job of the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192

    • If a specific commit is needed, submit it as a job variable (STABLE_BRANCH_SOURCE_COMMITS_INPUT) in the monthly_release_initial_rc:start job
    STABLE_BRANCH_SOURCE_COMMITS_INPUT='gitaly=123abc,gitlab=456def,gitlab_pages=678cba'

    See documentation for additional details

    • If no commit is provided, the tooling will use the latest commit deployed to production for the various components that we release. See the release candidates doc for detailed guidance.
    • When the monthly_release_initial_rc:start job is started, the initial RC will be tagged automatically.
    • 120 minutes after the initial RC is tagged, jobs to verify the RC pipelines and the deployment to preprod will be automatically triggered.

  • Verify that the release information dashboard reflects the accurate status "closed" for the active release version (18.6).

    • The updated status can take up to 15 minutes to display on the dashboard once the RC is tagged.

  • Notify Engineering Managers and developers that the initial release candidate has been created:

    /chatops run notify ":mega: The stable branch has been created and the release candidate is tagged. Barring any show-stopping issues, this is the final commit to be released on the 20th.
https://gitlab.com/gitlab-org/security/gitlab/-/commits/18-6-stable-ee
You can check if an MR made the cut by using the following ChatOps command: `/chatops run release check [MR_URL] 18.6`
* Documentation about `release check` chatops command: `https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/deploy/auto-deploy.md#status-of-a-merged-mr-with-respect-to-monthly-releases`
* When is the next Release? Check it on the 'Release Information' dashboard: https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1"

Note: If required, additional release candidates can be manually tagged before the final release candidate.

Final RC: Tuesday, 2025-11-18

Past this point, no new code can be added to the release that was not included in the final RC.

Tag day: Wednesday, 2025-11-19 (3rd Wednesday of the month)

  • Start the monthly_release_tag_day:prepare job in the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192
    • Jobs to verify the integrity of the stable branches (monthly_release_tag_day:ensure_stable_branches_green) and the mirror status (monthly_release_tag_day:mirror_status) will start automatically.
  • Once the above jobs are green, trigger the monthly_release_tag_day:start_tag job: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192
    • This job will tag the final 18.6.0 version.
  • The monthly_release_tag_day:check_omnibus_packages_tagging job in the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192 will be triggered 90 minutes after tagging completes. However, if possible, you can start it earlier. In case the job fails, troubleshoot the issue, and rerun the job.
  • Check that the CNG Images are built: CE | EE | UBI | FIPS.
  • Check that the Helm chart is built by making sure the publish_tagged_package job succeeded: v9.6.0
  • After tagging, the release.gitlab.net instance was automatically updated with the latest monthly release. Corroborate if the deployment was successful by verifying that the monthly_release_tag_day:verify_release_deploy job succeeded.
    • A Slack notification with Validate release.gitlab.net running 18.6.0 has successfully executed will be sent to #f_upcoming_release.
  • After tagging, the GitLab QA update scenario runs. Corroborate if the QA was successful by verifying that the monthly_release:update_paths stage succeeded.
    • A Slack notification with Update paths QA will be sent to #f_upcoming_release.
  • Validate 18.6.0 has been passed automated QA by ensuring the release-gitlab-qa-smoke job from the release.gitlab.net deploy pipeline is green.

Release day: Thursday, 2025-11-20 (3rd Thursday of the month)

Final release is tagged, so any changes will have to initiate a patch release. Reminder: We have a soft PCL today, coordinate with the EOC before deploying to production. Consider not running the post-deploy migration pipeline to keep rollback options available.

  • At 13:00 UTC, start the monthly_release_release_day:start job in the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192. An announcement will be sent and the publish will happen 10 minutes later automatically. In case you want to publish the release immediately, skip the delay time of the job monthly_release_release_day:publish.

    • ⚠️ Make sure that neither packages nor the blog post get published earlier than 13:10UTC without approval by the messaging lead of the release post. Mind that you don't need their approval if you're on time ⚠️
    • If anything goes wrong and the release is delayed, ping the release post manager on Slack to make them aware of the issue. Cross-post the slack message to the #marketing channel to notify them too

  • At 14:10 UTC:

    • Start the monthly_release_verify:start job in the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192
    • Make sure the monthly_release:verify stage has completed successfully.
    • Check that the CNG Images are published: Each version has 4 tags for ee, fips, ubi and the branch itself: CE | EE | UBI | FIPS
    • Check that the Helm chart is published by making sure the release_package job succeeded: v9.6.0
    • Post an update about the status in #f_upcoming_release 
    :mega: 18.6.0 is published and publicly available

  • Once all packages are available publicly and GitLab.com is up and running on the release version, ping the release post manager on Slack (#release-post channel) to give them a go to merge the release post at ~14:20 UTC, so that it will be live at 15:00 UTC

  • Start the monthly_release_finalize:start job in the monthly release pipeline: https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines/5094192

Release Certification

The release certification process may apply to this release. cc @gitlab-com/gl-security/product-security/federal-application-security

Edited by Akinyele Cafe-Febrissy