Add a release post retrospective issue (example) and provide a link to it at the top of this MR description with the text Process Improvements? Have suggstions for improving the release post process as we go? Capture them in the [Retrospective issue]().
Check the reviewers on Slack and add their names (and your own) replacing each @mention in the MR description checklists
Add milestone
Update the links and due dates in this MR description
Make sure the blog post have all initial files, as well as this MR template contains the latest template
Add authorship (author's data)
Ask the messaging lead to add the introduction by the 6th working day before the 22nd
Make sure all feature descriptions are positive and cheerful
Make sure all features listed in the direction
page are included in the post
Mention the Distribution PM asking them
if there's any relevant info to be added to the upgrade warning section. If not, delete the upgrade block in the relese post data file
Due date: 2019-06-14 (6th working day before the 22nd)
The Product Managers are responsible for adding their feature blocks to the
release post by the due date for general contributions. PMs are also responsible
for adding any notable Community Contributions.
PMs: please check your box only when all your features and deprecations were
added with completion (documentation links, images, etc). Pls don't check if
there are still things missing.
Note: be sure to reference your Direction items and Release features. All items which appear
in our Upcoming Releases page should be included in the relevant release post.
Mention the below individuals after feature freeze
Ideally, complete the review until the 4th working day before the 22nd,
so that the 3rd and the 2nd working day before the release
could be left for fixes and small improvements.
Content review
Due date: 2019-06-17 (5th working day before the 22nd)
Check image shadow applied correctly in release post data. Look for image_noshadow: true when an image already has shadow
Ensure videos and iframes are wrapped in <figure class="video_container"> tags (for responsiveness)
Ensure all text is consistently hard wrapped at a suitable column boundary
Check headings are in sentence case
Check feature and product names are in capital case
Check if images are harmonic/consistent
Check any .gitkeep files and delete them if any
Add or check cover img reference (at the end of the post). Data in cover_img in release post Yaml file
Ensure content is balanced between the columns (both columns are even)
Ensure links have meaningful text for SEO (e.g., "click here" is bad link text)
Check for badges consistency (applied to all headings)
Double check that all features are documented
Check that all links to about.gitlab.com content are relative URLs
Check the anchor links in the intro. All links in the release post markdown file should point to something in the release post Yaml file
Remove any remaining instructions (comments) from the release post files
Run a dead link checker, e.g., Check my Links and ping reporters directly on Slack asking them to fix broken links
Update the release post templates and release post handbook with anything that comes up during the process
Pull master into the release post branch and resolve any conflicts (again)
Report any problems from structural check in the #release-post channel by pinging the reporters directly for each problem. Do NOT ping @all or @channel nor leave a general message that no one will pay attention to. If possible, ensure any issues are tracked by open discussions in the merge request
Post a comment in the #company-announcements channel linking to the review app + merge request reminding the team to take a look at the release post and to report problems in #release-post. Template to use (replace links):
Hey all! This month's release post is almost ready! Take a look at it and report any problems in #release-post.MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1234Review app: https://release-12-0.about-src.gitlab.com/2019/06/22/gitlab-12-0-released/
At ~12:30 UTC, ping the release managers on the #releases Slack
channel asking if everything is on schedule, and to coordinate timing with them:
If anything is wrong with the release, or if it's delayed, you must ping
the messaging lead on #release-post so that they coordinate anything scheduled
on their side (e.g., press releases, other posts, etc).
If everything is okay, the packages should be published at 13:30 UTC, and available
publicly around 14:10 UTC.
Ask the release managers to ping you when the packs are publicly available (and GitLab.com is up and running on the release version)
Mention @sumenkovic to remind him to send the swag pack to the MVP
Check if all the anchor links in the intro are working
Check if there are no broken links in the review app (use a dead link checker, e.g., Check my Links)
Pull master and fix any conflicts
Check if there isn't any alert on Slack's #release-post and #company-announcements channels
Check if there isn't any alert on this MR thread
Check if the tweet copy is ready and someone is ready to share on social media
At 13:50 UTC
Check if there aren't any conflicts. If there are any, pull master again and fix them.
Once the release manager confirmed that the packages are publicly available:
Verify that the 11.0 to 12.0 YT video has been made public: "It's still unlisted on YT, so we need to be sure to make it public just before the post goes live."
Merge the MR at 14:10-14:20 UTC.
Wait for the pipeline. It should take ~40min to complete.
The post is to be live on the 22nd at 15:00 UTC. It should be merged and
as soon as GitLab.com is up and running on the new release version (or the latest
RC that has the same features as the release), and once all packages are publicly
available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes
about 40 min to run.
The usual release time is 15:00 UTC but it varies according to
the deployment. If something comes up and delays the release, the release post
will be delayed with the release.
Coordinate the timing with the
release managers. Ask them to
keep you in the loop. Ideally, the packages should be published around
13:30-13:40, so they will be publicly available around 14:10 and you'll
be able to merge the post at 14:20ish.
Once the post is live, wait a few minutes to see if no one spot an error
(usually posted in #company-announcements), then share on Twitter, Facebook, and LinkedIn,
or make sure someone (Emily vH, JJ, Marcia) does. Coordinate the social sharing
with them beforehand.
Keep an eye on Slack and in the blog post comments for a few hours to make sure
no one found anything that should be fixed.
Mek Stittri authored