Skip to content

Release 12.0.1

Preparation

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 12.0.1 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 12.0.1-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 v12.0.1

gitlab.com canary stage

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

  • Deploy 12.0.1 to canary vms in production

    # In Slack:
/chatops run deploy 12.0.1-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 12.0.1 to GitLab.com

    # In Slack:
/chatops run deploy 12.0.1-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 12.0.1

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

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

  • Create the 12.0.1 version on version.gitlab.com

  • Deploy the blog post

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

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

References

gitlab.com

dev.gitlab.org

Edited by Marin Jankovski