General availability tasks

These directions walk you through preparing for the release and tasks for GA day. Ideally this is done by a strategist/architect or a lead with a big-picture view of the doc, but as long as a teammate has rights, they can go through these procedures.

Prerequisites

You must have the following prerequisites to publish live:

  • Minimum KCS1 access to the Customer Portal and Pantheon
  • Connection to the VPN
  • Logged in to the Pantheon UI
  • Feature doc and release work is completed for GA

Preparing for Pencils Down

At some point the team agrees to a Pencils Down date, which may move depending on the product release. Close to that date, start preparing.

  1. Ensure the build is regularly green. Ask writers fix any errors for their books a few days before GA and work to keep the build green closer to the agreed upon Pencils Down day.
  2. Ask the team to work on reconciling the changes and merging active PRs to the stage branch. Since this depends on reviews and such, the PR list may not be clear in time, but no PRs for stage is the goal for Pencils Down.
  3. Declare Pencils Down on the date/time so that the team pauses any pushing to stage.
  4. Build stage. Check for green. Fix any errors.

Creating the production from stage

Now that stage is finalized and green, you can create the production branch from the stage branch. See Branch Strategy for important information about how and why we use these branches.

  1. Create the new _prod branch from the _stage branch.
  2. Protect the branch to keep anyone from bypassing rules in the production branch. Two users are needed to push stage into to prod: The creator and the reviewer. Go to Settings > Branches. (Because GitHub changes the UI at times, if this is not the workflow, you can simply Google something like “how to protect my branch in GitHub” for the process.)
  3. Select Add rule in the Branch protection rules section.
  4. Add the branch name to the Branch name pattern. Example: 2x_prod.
  5. Select Require a pull request before merging.
  6. Ensure that Require approvals is selected.
  7. Select Include administrators to prevent admins from bypassing this rule. Admins can bypass in stage IF needed, but not prod.
  8. Select Create to apply the rule.
  9. Run a build wit the prod branch in the command: ./acm_sync_asciidoc.sh 2.x 2.x_prod
  10. Ensure the build is clean.
  11. Stop any builds until GA day and after because prod and stage are in the same directory. You can return to building stage after you publish.

Publishing the doc and the splash page

Ideally the architect or strategist is doing this but can be done by the lead, with overall big-picture in mind. See support from the DE/PM about arranging this when needed.

  1. Log in to Pantheon.
  2. See the Publish a GA version section of Refreshing builds and complete the procedure.
  3. Click Splash Pages in the navigation to view the splash pages. If you are not logged in to Pantheon, you will not see this item in the navigation.
  4. Find the entry for Red Hat Advanced Cluster Management for Kubernetes. The entry should show the version of the product that you are pushing, with an unpublished label.
  5. Click the name of the product to open the splash page.
  6. Add the categories for the documentation and drag the books into the correct categories, if necessary.
  7. When you are ready to publish it, expand Update/view product status.
  8. Change the Product status from Unpublished to Published.
  9. Click Save to save the changes.

Additional tasks

  1. Publish the draft(s) for the Support Matrix. There should be an issue for the release that tracked this work. See the strategist or lead. Currently there is a matrix for ACM and MCE.
  2. Edit Comet. (?)
  3. Add the Support matrix to the Lifecycle page.
  4. Double check that links to the Support matrix work after you publish.