Release post - GitLab 14.2
Process Improvements? Have suggestions for improving the release post process as we go? Capture them in the Retrospective issue #12263 (closed).
- Preview page (shows latest merged content blocks for reference till the 17th): https://about.gitlab.com/releases/gitlab-com/
- View App (shows introduction, MVP and latest merged content blocks for reference 18th - 21st: https://release-14-2.about.gitlab-review.app/releases/2021/08/22/gitlab-14-2-released/index.html
Release post:
- Intro: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/sites/uncategorized/source/releases/posts/2021-08-22-gitlab-14-2-released.html.md
- Items: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/data/release_posts/14_2
- Images: https://gitlab.com/gitlab-com/www-gitlab-com/tree/release-14-2/source/images/14_2
Related MRs:
- Bug Fixes: !87949 (merged)
- Usability improvements: !87951 (merged)
- Performance improvements: !87950 (merged)
- MVP Nomination: #12268 (closed)
Related files:
- Features YAML link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/data/features.yml
- Features YAML Images link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/source/images/feature_page/screenshots
- Homepage card: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/sites/uncategorized/source/includes/home/ten-oh-announcement.html.haml
- MVPs: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-14-2/data/mvps.yml
Release post branch ownership:
- The Release Post Manager is solely in charge of changes to the release post branch. To avoid potential merge conflicts later during content assembly, it is imperative that Technical Writers do not merge updates from
master
to the release post branch even if it is falling behind or if there is a conflict. The Release Post Manager will take care of conflicts as part of the content assembly process on the 18th and work with the Technical Advisor as needed.
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 | Technical Advisor | Social | Product Operations DRI |
---|---|---|---|---|
@tmccaslin | @eread | @csouthard | DRI: @wspillane & @social for Slack Checklist item | @fseifoddini |
@tmccaslin) ✅
Release post kickoff (
Before starting on this checklist, you should have created the release post branch and required files as explained in the Handbook Note: Throughout the release post process, you'll do various Slack reminders/announcements. It is recommended you cc @fseifoddini and the rest of your release post team as you do these Slack posts because it helps keep everyone on the same page.EXPAND DETAILS - Due date: 2021-08-07 (By the 7th)
Release Post X.Y Retrospective
as a title. Once created, update the link at the top of this MR description. Example retro issue.
@mention
in this MR description with the names of the Release Post Manager, Tech Writer, and Social Lead for this releasesites/uncategorized/source/releases/posts/2021-08-22-gitlab-14-2-released.html.md
, data/release_posts/14_2/mvp.yml
and data/release_posts/14_2/cta.yml
sites/uncategorized/source/releases/posts/2021-08-22-gitlab-X-Y-release.html.md
X-Y-release-post-prep
channel in Slack, and invite @eread, @parker_ennis, @csouthard, @fseifoddini and the release post manager shadow (whoever is running the next release post. Let them know this channel is to discuss production specific topics that don't concern the broader team, so we can keep #release-post focused and easy to follow. As a topic, add the release post MR, the link to the review app, and the link of the retro issue:MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/87948
Review App: https://release-14-2.about.gitlab-review.app/releases/2021/08/22/gitlab-14-2-released/
Retro issue: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/12263
MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/87948
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-14-2.about.gitlab-review.app/releases/2021/08/22/gitlab-14-2-released/
master
to the release post branch. See the section Release post branch ownership
above for more details.
@tmccaslin) ✅
Release post item creation reminders (
Note: Throughout the release post-process, you'll do various Slack reminders/announcements. It is recommended you cc @fseifoddini and the rest of your release post team as you do these Slack posts because it helps keep everyone on the same page. Due date: 2021-08-10 (By the 10th)EXPAND DETAILS
@gitlab-com/backend-managers
and @gitlab-org/frontend/frontend-managers
in the comments of this MR, asking them to add their notable team performance improvements and bugs fixes to the MRs you've created by providing them with the direct links@gitlab-com/backend-managers
and @gitlab-org/frontend/frontend-managers
and share it in Slack #development and Slack #eng-managers as well
@tmccaslin ✅
Recurring items starting on the 12th:
General Content Review
As PMs finalize their release post items it can be helpful for the RPM to review and offer feedback. This reduces pressure on the 17th as items are merged and provides additional review from someone with a fresh perspective. You can start this as early as the 12th, but this should be an ongoing task leading up to content assembly on the 18th. Review each MR labeled Ready for content that follows handbook guidance. See What RPM should look for when reviewing content blocks. To easily manage and track reviewed items do the following: Reminding and Alerting DRIs It's important to keep DRIs up to date regularly with items they need to deliver for the release post. Especially given how async and distributed GitLab team members are early reminders are very helpful. The release post is authored following a changelog-style system.
Each item should be in an individual YAML file.EXPAND DETAILS
@tmccaslin
General contributions
Contribution instructions
See Handbook: Contributing to the release post.
Content blocks
Due date: 2021-08-10 (10th)
Product Managers are responsible for raising MRs for their content blocks and ensuring they are reviewed by necessary contributors by the due date. Content blocks should also be added for any epics or notable community contributions that were delivered.
Product Managers are also responsible for making sure all required (Tech Writing) and recommended (PM Director and PMM) reviews get done for their content blocks. To help reviewers prioritize what to review, PMs should communicate which content blocks are most important for review by applying the proper labels to the release post item MR prior to assigning the MR to reviewers. (ex: Tech Writing, Direction, Deliverable, etc). PMs can also follow these guidelines to help decide which content blocks should get PM Director and PMM reviews.
To enable Engineering Managers to merge the content blocks as soon as an issue has closed, PMs should ensure all scheduled items have MRs created for them and have the Ready label applied when content contribution and reviews are completed.
Product Managers should only check their box below when all their content blocks (features, deprecations, etc.) are complete (documentation links, images, etc.). Please don't check the box if there are still things missing.
Reminder: 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 ( @ogolowinski
) -
Compliance ( @stkerr
) -
Import ( @hdelalic
) -
Optimize ( @ogolowinski
)
-
- Create
-
Source Code ( @sarahwaldner
) -
Code Review ( @phikai
) -
Editor ( @ericschurter
) -
Gitaly ( @mjwood
)
-
- Ecosystem
-
Integrations ( @mushakov
) -
Foundations ( @mushakov
-
- Plan
-
Project Management ( @gweaver
) -
Product Planning ( @cdybenko
) -
Certify ( @mjwood
)
-
- Verify
-
Pipeline Execution ( @jreporter
) -
Pipeline Authoring ( @dhershkovitch
) -
Runner ( @DarrenEastman
) -
Testing ( @jheimbuck_gl
)
-
- Package
-
Package ( @trizzi
)
-
- Release
-
Release ( @kbychu
)
-
- Configure
-
Configure ( @nagyv-gitlab
)
-
- Monitor
-
Monitor ( @kbychu
@crystalpoole
)
-
- Secure
-
Static Analysis ( @tmccaslin
) -
Dynamic Analysis ( @derekferguson
) -
Composition Analysis ( @NicoleSchwartz
) -
Threat Insights ( @matt_wilson
) -
Vulnerability Research ( @tmccaslin
)
-
- Protect
-
Container Security ( @sam.white
)
-
- ModelOps
-
Applied Machine Learning ( @tmccaslin
)
-
- Growth
-
Activation ( @jstava
) -
Conversion ( @s_awezec
) -
Expansion ( @s_awezec
) -
Adoption ( @mkarampalas
) -
Product Intelligence ( @amandarueda
)
-
- Fulfillment
-
Purchase ( @tgolubeva
) -
License ( @teresatison
) -
Utilization ( @amandarueda
)
-
- Enablement
-
Distribution ( @dorrino
) -
Geo ( @nhxnguyen
) -
Memory ( @fzimmer
) -
Global Search ( @JohnMcGuire
) -
Database ( @fzimmer
) -
Sharding ( @fzimmer
) -
Infrastructure ( @awthomas
)
-
- Mobile Apps (
@david
) - Five Minute Production App (
@kencjohnston
)
✅
Recurring content blocks
Due date: 2021-08-10 (10th) The following sections are always present and managed by the PM or Eng lead
owning the related area. Due date: 2021-08-15 (15th) Due date: 2021-08-17 (17th) 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 automating this process both so it's less error-prone and to make the notes more accurate to release cut.EXPAND DETAILS
@DarrenEastman
!87352 (merged)
@dorrino
!88139 (merged)
@dorrino
!87948 (comment 646550575)
Content Block Final Merge
@tmccaslin) ✅
Content assembly and initial review (
Note: Due date: 2021-08-12 (12th) Due date: 2021-08-15 (15th) Due date: 2021-08-17 (17th) Due date: 2021-08-18 (18th at 8 AM PT and NO earlier) Note: If the release post assembly script fails, look at the bottom of this section of the release post handbook page for further instruction Due date: 2021-08-18 (18th) Due date: 2021-08-20 (20th)EXPAND DETAILS
Final Content Assembly
, and Structural Check
steps all happen in sequence on the 18th starting ~8am PST (America/Los_Angeles
). If the Release Post Manager and Technical Writer span many timezones it's recommended you coordinate ahead of the 18th to understand how this could impact working hours for each team member. If need be, the time of initiating the final content assembly
and the subsequent coordinated tasks can be shifted, as long as Final content review
with the CEO and CProdO begin no later ~12pm PST on the 19th, to allow enough time for feedback/updates.
source/images/
directory and use the search bar in the Finder to search for cover
. Make sure the scope is set to only search "images". This won't reveal all previous images, but the last couple of years have had pretty consistent naming.release-14-2
branch, add the cover image to source/images/14_2/14_2-cover-image.jpg
. Tip: Be sure to use an _
between release numbers, not a -
release-14-2
branch, in sites/uncategorized/source/releases/posts/2021-08-22-gitlab-14-2-released.html.md
, add details about the source image.
data/release_posts/14_2/mvp.yml
on the release-14-2
branchrelease-14-2
branch, add the MVP's name and other profile info to data/mvps.yml
git checkout master
git pull
git checkout release-14-2
git pull
git merge master
bin/release-post-assemble
git push origin release-14-2
@anoop
in the appropriate section of this MR and ask him to add a Suggestion to update the intro, choosing no more than 4 features to highlight in order of importance. The top 2 features will used in the title of the post and the top 1 feature will be appear as the first feature in the release notes.#define-test-cases-in-gitlab
top
while the rest can remain primary
or secondary
.release-14-2
branch, update the release blurb for the homepage in the file: /sites/uncategorized/source/includes/home/ten-oh-announcement.html.haml
changing the following lines:
%h1 X.X
line to the latest verion.GitLab X.X released with Feature A and Feature B
.link_to
line with the URL of the blog. For example, /releases/2021/06/22/gitlab-14-0-released/
. "name":"GitLab X.X"
line to the latest version."releaseNotes":"https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/"
."softwareVersion":"X.X"
line to the latest version.
View App
, asking them to make sure all their content is showing up as expected with correct image/video links, etc. and that as confirmation of their final review, to check off their content and recurring blocks in the release post MR.
/data/release_posts/14_2
on the current release-14-2
branch.
Other reviews
Ideally, complete the reviews by the 19th of the month, so that the 2 days before the release can be left for fixes and small improvements.
Structural check (Technical Writing Lead)
Due date: 2021-08-18 (18th)
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. For example: 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. The TW lead is also responsible for ensuring that the next version of the documentation site is published to match the current release. This process should start around the same time as the release post structural check, and finish on or near the 22nd. In the In the review app: In general:EXPAND DETAILS
The structural check is performed by the technical writing lead: @eread
this is a typpo
www-gitlab-com
repository:
name
contains backticks when referring to code. (Previously we had to use single quotes, but backticks work now.).gitkeep
files accidentally included.cover_img:
license block (at the end of the post). Should include image_url:
, license:
, license_url:
.available_in: [free, premium, ultimate]
and change to available_in: [core, premium, ultimate]
.
gitlab-ci.yml
and ensure there is a period before the filename, for example, .gitlab-ci.yml
.
#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.#whats-happening-at-gitlab
channel linking to the View App + merge request reminding the team to take a look at the release post and to report problems in #release-post
. CC the release post manager. Template to use (replace links):
Hey all! This month's release post is almost ready! Take a look at it and either
report any problems in #release-post, or leave a comment to the release post MR.
MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1234
View app: https://release-14-2.about.gitlab-review.app/releases/2021/08/22/gitlab-14-2-released/index.html
Slack X-Y release post prep
channel.
@tmccaslin)
Final content review (
Due date: 2021-08-19 (18th - 19th) Incorporating Feedback - Due date: 2021-08-20 (by the 20th) Once the release manager confirmed that the packages are publicly available by pinging you in Slack: For assistance related to failed pipelines or eleventh-hour issues merging the release post, reach out to release post technical advisors for assistance in the EXPAND DETAILS
@sytse
, @sfwgitlab
, and @adawar
in #release-post on Slack when the post has been generated for their review per these communication guidelines
@adawar
identify the 3-7 items for **What's New ** by posting in Slack #release-post and linking him to Creating an MR for What's New entries in the handbook. cc What's new DRIs Product operations '@fseifoddiniand Growth
@mkarampalas` in the Slack post.
titles
in the content blocks. More information to consider about altering secondary items here | technical instructions
@fseifoddini
) for final check in Slack #release-post
@tmccaslin)
Preparing to merge to master (
On the 21st
@community-team
on Slack #swag to ask them to send the swag pack to the MVP/data/release_posts/14_2
on the current release-14-2
branch.master
into your release post branch before the 22nd. This prevents having to resolve conflicts when merging the release post branch into master
on the 22nd. This issue shows an example of how this process can be handled: #10886 (closed).
@tmccaslin)
On the 22nd (
At 12:30 UTC
#releases
slack channel to let the release managers you're online and await their que in #release-post
to start the merge process of the release post.
#release-post
if there are any issues with the release. You can follow along on the release issue to see the packaging progress on the 22nd | issue list example issue. The #releases
slack channel is also a good place to track any updates or announcements.#release-post
and #whats-happening-at-gitlab
channels
@tmccaslin)
Merging to master (
At 13:50 UTC
#release-post
Slack channel; be sure to include the live URL link and social media copy (you can copy/paste the final copy from the View app).
#release-posts
and #whats-happening-at-gitlab
channels on Slack.
What to do if your pipeline fails or you have other technical problems#dev-escalation
Slack channel. Cross-post the thread from #dev-escalation in #release-post so all Product Managers and release post stakeholders are aware of status and delays.
Important notes
handoff to social team
checklist item above.#release-post
and in the #whats-happening-at-gitlab
Slack channels.