Blog Post - Document how to implement incremental rollouts with GitLab CI
All threads resolved!
Engineer(s): @sean_carroll | Product Marketing: @williamchia | Tech Writer: @marcia | Engineering Manager: @darbyfrey
Please review the guidelines for feature block creation at https://about.gitlab.com/handbook/marketing/blog/release-posts/#feature-blocks. They are frequently updated, and everyone should make sure they are aware of the current standards (PM, PMM and TW).
image_noshadow: true
when an image already has a shadow.data/features.yml
(with accompanying screenshots).available_in:
) is correct: (Core, Starter, Premium, Ultimate).<figure class="video_container">
tags (for responsiveness).documentation_link:
), and includes the anchor to the relevant section on the page if possible. If documentation is not yet available/merged for the feature in question, you may use a placeholder or use the link where the documentation will be added (often the engineer and tech writer know this ahead of time). Be sure to update this placeholder prior to publication if you do not use the final link.about.gitlab.com
content are relative URLs.When the above is complete and the content is ready for review, it should be reviewed by Product Marketing, Tech Writing, and the product director for this area. Please assign them when it is ready to be reviewed!
'
(documentation_link: 'https://docs.gitlab.com/ee/#amazing'
)."
(name: "Lorem ipsum"
).Once all content is reviewed and complete, add the Ready label and assign this issue to the engineering manager. The EM is responsible for merging as soon as the implementing issue is deployed to GitLab.com, after which this content will appear on the GitLab.com Release page and can be included in the next release post. All release post items must be merged on or before the 17th of the month. If a feature is not ready by the 17th deadline, the EM should push the release post item to the next milestone.