Skip to content

Updates monthly release template

Mayra Cabrera requested to merge update-monthly-release-template into master

What does this MR do?

  • Creates a new section called "Up to the 17th" with what we usually do during those days.
  • Restore 'posting to Slack channels' step once the stable branch was created
  • Fixes packages links
  • Other minor adjustments

Example

Monthly Release template example # Release 13.3

First steps

  • Change #f_upcoming_release topic with /topic 13.3.0: <link_to_this_issue>
  • Modify the dates below to accurately reflect the plan of action

Up until the 17th

17th

If this date is on a weekend, do this work on the next working day

  • Find the latest sha that made it into production successfully: sha
  • Notify Engineering Managers that this is the sha that is guaranteed to be released on the 22nd, in #releases: 
    :mega: This is the most recent commit running on GitLab.com and this is guaranteed to be released on the 22nd.
https://gitlab.com/gitlab-org/gitlab/commits/<SHA>
Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`
  • Link the above message to additional channels: #development, #backend, and #frontend

18th

If this date is on a weekend, do this work on the last Friday before the 18th.

  • Log latest auto-deploy branch: BRANCH_NAME
  • Ensure this build makes it through into production
  • Grab the sha from this new auto-deploy branch and notify Engineering Managers that this is the candidate sha for the release, in #releases: 
    :mega: This is the _candidate_ commit to be released on the 22nd.
https://gitlab.com/gitlab-org/gitlab/commits/<SHA>
Please see the following documentation on what this means:
  * `https://about.gitlab.com/handbook/engineering/releases/#how-can-i-determine-if-my-merge-request-will-make-it-into-the-monthly-release`
  * `https://about.gitlab.com/handbook/engineering/releases/#when-do-i-need-to-have-my-mr-merged-in-order-for-it-to-be-included-into-the-monthly-release`
  • Link the above message to additional channels: #development, #backend, and #frontend

20th: two working days before the release

If this date is on the weekend, do this work on the last Friday before the 20th.

  • Determine what the last green auto deploy branch is and add it here: BRANCH

  • Create the stable branches using chatops by running the following in Slack: /chatops run release stable_branch 13.3.0

  • Verify that the CE stable branch contains the right commits

    • There should be at least two commits: the last commit from the previous stable branch (usually a version update), and the sync commit created by the merge train.
    • The sync commit will have the message "Add latest changes from gitlab-org/gitlab@13-3-stable-ee"

  • Create a RC version to ensure that the final version builds correctly

    # In Slack:
/chatops run release tag 13.3.0-rc42

  • Notify Engineering Managers that final candidate has been created in #releases:

    :mega: Barring any show-stopping issues, this is the final commit to be released on the 22nd.
https://gitlab.com/gitlab-org/gitlab/-/commits/13-3-stable-ee

  • Link the above message to additional channels: #development, #backend, and #frontend

21st: one day before the release

Instructions for manual deploy 
    ```sh
    # In Slack:
    /chatops run deploy 13.3.0-ee.0 --release
    ```
  • Validate 13.3.0 has been passed automated QA

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

22nd: release day

Final release is tagged, so any changes will have to initiate a patch release.

  • At 13:00 UTC, post an update about the package building status in #f_upcoming_release
  • At 13:30 UTC:
    • ⚠ Make sure that neither packages nor the blog post get published earlier than 13:30UTC without approval by the messaging lead of the release post. Mind that you don't need their approval if you're on time ⚠
    • Publish the packages via ChatOps: 
      # In Slack:
/chatops run publish 13.3.0
    • 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:
    • Verify that EE packages appear on packages.gitlab.com: EE (should contain 14 packages)
    • Verify that CE packages appear on packages.gitlab.com: CE (should contain 13 packages)
    • Verify that Docker images appear on hub.docker.com: EE / CE
    • Create the 13.3.0 version on version.gitlab.com
    • Post an update about the status in #f_upcoming_release
    • 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
  • Open MR to Bump VERSION file to the next version to be released
Edited by Mayra Cabrera

Merge request reports