Skip to content

Release 11.11.3

Preparation

  • Preparation MR's should already be created

  • Ensure any backports targeting 11.11.3 are merged to their stable counter part

  • Perform automated merging into the preparation branches:

    # In Slack
/chatops run release merge 11.11.3

  • Ensure the CE preparation MR has been fully merged into the EE counterpart

  • Merge the preparation branches

  • For omnibus-gitlab add the changes to the stable branches:

    • Before the 7th: merge master into the CE stable branch, then merge the CE stable branch into EE.
    • After the 7th: cherry-pick remaining merge requests directly into CE stable branch. Then, merge the CE Omnibus stable branch into EE.

  • Check the following list of critical issues/MRs which are to be included in 11.11.3. Ensure each has made both CE and EE:

    • REFERENCE_TO_MR_TO_PICK

  • Ensure builds are green on Omnibus CE stable branch and Omnibus EE stable branch

Packaging

Deploy

Deploys to production require confirmation from a production team member before proceeding. Use /chatops run oncall production in the #production channel to find who's on call and ping someone. Deploys to staging or canary can be done at will, just mention it in the #production channel.

staging.gitlab.com

  • Inform the oncall in the #production channel about staging deploy
  • Check if there are any post-deployment patches that need to be re-applied. If there are, the deployment must be halted and assessed as to the impact of undoing the patches because of the release. To proceed, approval must be given by the manager oncall.
  • Deploy 11.11.3 to staging.gitlab.com. Note that starting in release 11.6 staging deploys are automatically triggered from the EE omnibus pipeline gitlab_com:upload_deploy stage. 
    # In Slack:
/chatops run deploy 11.11.3-ee.0
  • Link to deployment job (even failed attempts) =>

QA

The QA task issue is generated automatically when deploying to staging. If you need to manually generate the QA task, you can do so as follows:

# In Slack, replacing LAST_DEPLOYED_VERSION with the appropriate value:
/chatops run release qa vLAST_DEPLOYED_VERSION v11.11.3

gitlab.com canary stage

  • Inform the oncall in the #production channel about canary deploy

  • Deploy 11.11.3 to canary vms in production

    # In Slack:
/chatops run deploy 11.11.3-ee.0 --production --canary

  • Link to deployment job (even failed attempts) =>

  • Confirm that there are no errors on canary

If there are issues on canary you should immediately stop sending traffic to it by issuing the following chatops command:

/chatops run canary --drain --production

gitlab.com main stage (production)

  • Wait for the QA Task deadline to pass before deploying to the rest of gitlab.com

  • Confirm there are no critical alerts on gitlab.com on the alerting dashboard

  • Get confirmation from a production team member to deploy to production In #production, use /chatops run oncall production to find who's on call, and @mention them asking to deploy to production

  • If someone besides the oncall confirms, @mention the oncall so they are aware.

  • Deploy 11.11.3 to GitLab.com

    # In Slack:
/chatops run deploy 11.11.3-ee.0 --production

  • Link to deployment job (even failed attempts) =>

  • Check if there are any post-deployment patches that need to be re-applied. If there are, the deployment must be halted and assessed as to the impact of undoing the patches because of the release. To proceed, approval must be given by the manager oncall.

Release

  • Publish the packages via ChatOps:

    # In Slack:
/chatops run publish 11.11.3

  • Verify that packages appear on packages.gitlab.com: EE / CE

  • Verify that Docker images appear on hub.docker.com: EE / CE

  • Create the 11.11.3 version on version.gitlab.com

  • Deploy the blog post

  • Post a tweet about the 11.11.3 release in the #releases channel:

    !tweet "GitLab 11.11.3 is now available: [BLOG_POST_URL] [DESCRIPTION_OF_CHANGES]"

References

gitlab.com

dev.gitlab.org

Edited by John Skarbek