Release post - GitLab 12.9
Process Improvements? Have suggestions for improving the release post process as we go? Capture them in the Retrospective issue.
Review Apps: https://release-12-9.about.gitlab-review.app/releases/2020/03/22/gitlab-12-9-released/index.html
Release post:
- Intro: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/source/releases/posts/2020-03-22-gitlab-12-9-released.html.md
- Items: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/data/release_posts/12_9
- Images: https://gitlab.com/gitlab-com/www-gitlab-com/tree/release-12-9/source/images/12_9
Related files:
- Features YAML link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/data/features.yml
- Features YAML Images link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/source/images/feature_page/screenshots
- Homepage card: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/source/includes/home/ten-oh-announcement.html.haml
- MVPs: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-12-9/data/mvps.yml
Handbook references:
- Blog handbook: https://about.gitlab.com/handbook/marketing/blog/
- Release post handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/
- Markdown guide: https://about.gitlab.com/handbook/engineering/technical-writing/markdown-guide/
People:
- Release Post Managers: https://about.gitlab.com/handbook/marketing/blog/release-posts/managers/
- Release Managers: https://about.gitlab.com/community/release-managers/
Release post manager | Tech writer | Messaging | Social |
---|---|---|---|
@ljlane | @axil | @supadhyaya | DRI: @wspillane & @social for Slack Checklist item |
Initial checklist (Author)
Due date: 2020-03-10
Remind release post contributors that content deadlines are approaching: @ljlane
-
Remind Product Managers that all feature blocks should be drafted, and under review by the 10th. All direction items and notable community contributions should be included in the release post. -
Remind recurring block authors that content is due by the 10th
The PM leading the release post is responsible for adding and checking the following items: @ljlane
-
Label MR: ~"blog post" release release post ~P1 -
Assign the MR to yourself -
Create a release post retrospective issue (example) and update the link at the top of this MR description -
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) -
Add cover image ( image_title
) (compressed) -
Add social sharing image ( twitter_image
) (compressed) -
Mention managers to remind them to add their team performance improvements: @gitlab-com/backend-managers
and@gitlab-org/frontend/frontend-managers
-
Mention managers to remind them to add their team bug fixes: @gitlab-com/backend-managers
and@gitlab-org/frontend/frontend-managers
-
Alert people one working day before each due date (post a comment to #release-post Slack channel)
General contributions
The release post is authored following a changelog style system. Each item should be in an individual YAML file.
Contribution instructions
See Handbook: Contributing to the release post.
Feature blocks
Due date: 2020-03-10
Product Managers are responsible for raising MRs for their feature blocks and ensuring they are reviewed by necessary contributors by the due date. PM Section lead, and PMM reviews are highly recommended, but the Tech Writer review is the only one required for inclusion in the Release Post. The Tech Writing review should be focused on looking for typos, grammar errors, and helping with style. PMs are responsible for coordinating any significant content/tech changes. Communicating priority about which release post items are most important for review will help Product Section leads, PMMs, and Tech Writers review the right items by the 10th of each month, so ensure the proper labels ares applied to the MR and assign reviewers to the MR when it is ready for them to review (ex: Tech Writing
, Direction
, Deliverable
, etc).
Feature blocks should also include any epics or notable community contributions that were delivered.
To enable Engineering Managers to merge their feature blocks as soon as an issue has closed, please ensure all scheduled items you want to include in the release post have feature blocks MRs created for them and have the Ready
label applied when content contribution and reviews are completed.
Product Managers: please check your box only when all your features and deprecations content is complete (documentation links, images, etc.). Please 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. For more guidance about what to include in the release post please reference the Product Handbook.
- Manage
-
Access ( @jeremy
) -
Analytics ( @jeremy
) -
Compliance ( @mattgonzales
) -
Import ( @hdelalic
) -
Spaces ( @tipyn
)
-
- Create
-
Source Code ( @jramsay
) -
Knowledge ( @cdybenko
) -
Static Site Editor ( @ericschurter
) -
Editor ( @phikai
) -
Gitaly ( @jramsay
) -
Gitter ( @ericschurter
)
-
- Plan
-
Project Management ( @gweaver
) -
Portfolio Management ( @kokeefe
) -
Certify ( @mjwood
)
-
- Verify
-
Continuous Integration ( @thaoyeager
) -
Runner ( @DarrenEastman
) -
Testing ( @jheimbuck_gl
)
-
- Package
-
Package ( @trizzi
)
-
- Release
-
Progressive Delivery ( @ogolowinski
) -
Release Management ( @jmeshell
)
-
- Configure
-
Orchestration ( @danielgruesso
) -
System ( @nagyv-gitlab
)
-
- Monitor
-
APM ( @dhershkovitch
) -
Health ( @williamchia
)
-
- Secure
-
Static Analysis ( @tmccaslin
) -
Dynamic Analysis ( @derekferguson
) -
Composition Analysis ( @NicoleSchwartz
) -
Attack Surface ( @stkerr
)
-
- Defend
-
Container Security ( @sam.white
) -
Threat Insights ( @matt_wilson
)
-
- Growth
-
Fulfillment ( @mkarampalas
) -
Retention ( @mkarampalas
) -
Telemetry ( @sid_reddy
) -
Expansion ( @timhey
) -
Conversion ( @s_awezec
) -
Acquisition ( @jstava
)
-
- Enablement
-
Distribution ( @ljlane
) -
Geo ( @fzimmer
) -
Memory ( @joshlambert
) -
Ecosystem ( @deuley
) -
Search ( @phikai
) -
Database ( @joshlambert
)
-
Recurring blocks
Due date: 2020-03-15
The following sections are always present and managed by the PM or Eng lead owning the related area.
-
Add GitLab Runner improvements: @DarrenEastman
-
Add Omnibus improvements: @ljlane
-
Add Mattermost update to the Omnibus improvements section: @ljlane
Final Merge
Due date: 2020-03-17
Engineering managers listed in the MRs are responsible for merging as soon as the implementing issue(s) are officially part of the release. All release post items must be merged on or before the 17th of the month. Earlier merges are preferred whenever possible. If a feature is not ready and won't be included in the release, the EM should push the release post item to the next milestone.
To assist managers in determining whether a release contains a feature. The following procedure documented here is encouraged to be followed. In the coming releases, Product Management and Development will prioritize to automate this process both so it's less error prone and to make the notes more accurate to release cut.
Content assembly (Author)
The PM leading the post is responsible for adding and checking the following items: @ljlane
Due date: 2020-03-18
-
Pull master
, resolve any conflicts -
Move items from data/release_posts/unreleased/
todata/release_posts/12_9/
-
Move referenced images in /source/images/unreleased/
to/source/images/12_9/
. -
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 release post data file -
Confirm team performance improvements have been included: @gitlab-com/backend-managers
and@gitlab-org/frontend/frontend-managers
-
Confirm team bug fixes have been included: @gitlab-com/backend-managers
and@gitlab-org/frontend/frontend-managers
-
Ask the messaging lead to add the introduction by the 2nd working day before the 22nd -
Check with the Messaging Lead on what the top features should be. -
Check if deprecations are included -
Add MVP (MVP block) -
Make sure the PM for the MVP feature adds a corresponding feature block if applicable, linking from the MVP section -
Add MVP to data/mvps.yml
-
Make sure all images (png, jpg, and gifs) are smaller than 300 KB each -
Run the release post through an automated spell and grammar check -
Perform the content review
Review
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: 2020-03-18 (18th)
Performed by the author of the post: @ljlane
-
Label MR: ~"blog post" release review-in-progress -
Run the content through an automated spelling and grammar check -
Check if there are no broken links in the review app (use a dead link checker, e.g., Check my Links) -
Check all comments in the thread (make sure no contribution was left behind) -
Reorder primary and secondary features according to their relevance to the user (most impactful features come first, items are sorted by filename) -
Make sure all discussions in the thread are resolved -
Mention @sfwgitlab
,@kencjohnston
,@jyavorska
,@ebrinkman
, and@joshlambert
to remind them to review (directors do not need to re-review individual items.) -
Mention @sytse
in #release-post on Slack when the post has been generated for his review -
Assign the MR to the next reviewer (structural check) -
Lock features.yml
with File Locking on the 21st
Structural check
Due date: 2020-03-19
The structural review is performed by a technical writer: @axil
For suggestions that you are confident don't need to be reviewed, change them locally and push a commit directly to save the PMs from unneeded reviews. Ex:
- clear typos, like
this is a typpo
- minor front matter issues, like single quotes instead of double quotes, or vice versa
- extra whitespace
For any changes to the content itself, make suggestions directly on the release post diff, and be sure to ping the reporter for that block in the suggestion comment, so that they can find it easily.
-
Add the label review-structure. -
Pull master
into the release post branch and resolve any conflicts. -
Check frontmatter entries and syntax. -
Check that images make sense and render fine. -
Remove any .gitkeep
files accidentally included. -
Add or check cover_img:
license block (at the end of the post). Should includeimage_url:
,licence:
,licence_url:
. -
Ensure content is balanced between the columns (both columns are even). -
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. -
Run a dead link checker, e.g., Check my Links and ping reporters directly on Slack asking them to fix broken links. -
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 to which no one will pay attention. If possible, ensure open discussions in the merge request track any issues. -
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/42056 Review app: https://release-12-9.about.gitlab-review.app/releases/2020/03/22/gitlab-12-9-released/index.html
-
Remove the label review-structure. -
Assign the MR to the next reviewer (Marketing). -
Within 1 week, update the release post templates and release post handbook with anything that comes up during the process.
Further reviews
Due date: 2020-03-20
-
Marketing review (PMMs - messaging lead): @supadhyaya -
Write the introduction (by the 6th working day before the 22nd) -
Write social sharing text for the tweet announcement after the release post is live -
Check/copyedit feature blocks -
Check/copyedit features.yml
-
Check/copyedit homepage blurb (check /source/includes/home/ten-oh-announcement.html.haml) -
Mention Scott W. ( @sfwgitlab
) for final check -
Remove the label review-in-progress -
Assign the MR back to the author
-
On the 22nd
The author of the post is responsible for merging the MR and following up with possible adjustments/fixes: @ljlane.
At 12:00 UTC
-
Read the important notes below -
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)
- If anything is wrong with the release, or if it's delayed, you must ping
the messaging lead on
-
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 social media copy is ready
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:
-
Unlock features.yml
just before merging. -
Merge the MR at 14:10-14:20 UTC. -
Wait for the pipeline. It should take ~40min to complete. -
Check the look on social media with Twitter Card Validator and Facebook Debugger. -
Check for broken links again once the post is live. -
Handoff social posts to the social team and confirm that it's ready to publish: Mention @social in the #release-post
Slack channel; be sure to include the link and social media copy.- A member of the social team will schedule the posts at the next available best time on the same day. The social team will mark the Slack message with a
⏳ once scheduled and add cheduled times to the post thread for team awareness. Further details are listed below in the Important Notes Section.
- A member of the social team will schedule the posts at the next available best time on the same day. The social team will mark the Slack message with a
-
Share the links to the post on the #release-posts
and#company-announcements
on Slack.
Important notes
- 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 (https://about.gitlab.com/community/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 release post is live, wait a few minutes to see if no one spots an error (usually posted in #company-announcements), then follow the
handoff to social team
checklist item above. - The tweet to share on Slack will not be live, it will be scheduled during a peak awareness time on the 22nd. Once the tweet is live, the social team will share the tweet link in the
#release-post
and in the#company-announcements
Slack channel. - Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that needs fixing.