Skip to content

Latest commit

 

History

History
119 lines (78 loc) · 6.3 KB

RELEASE-PROCESS.md

File metadata and controls

119 lines (78 loc) · 6.3 KB
Raw

Release process

  1. Publish to NPM

    1. Checkout the latest master branch and ensure that you don't have any local changes. If you do have local changes stash or discard them before going to the next step.

    2. Check for unexpected visual regressions. The app must be running locally in order for the tests to run, so run yarn start if the app isn't up already.

      backstop test

      If there are expected visual changes, run backstop approve to save the new reference files. This should ideally be handled before the release process begins.

    3. Ensure you are logged into NPM. Check your user account with npm whoami.

      Note: You must be logged in to an NPM account with publishing rights on the cmsgov organization. To request access, create a Jira ticket on the QPP Tools and Access board with your EUA and NPM username. Reach out on the #cms-design-system channel for any questions on this process.

    4. Run the pre-release script to prepare the repo for publishing.

      yarn pre-release

      This script will install dependencies, build design system assets, and run the linter and tests. If everything passes, lerna will prompt you for the new version number, which should follow the SemVer release format. After the versions are updated, the script will create a tagged release commit (prefaced with core-), a branch (prefaced with release-) containing the release commit, and a zip for the Github release notes.

    5. After the pre-release script is completed, unpack the release zips created from the release script (i.e. cmsgov-design-system-2.0.0.tgz) and check the relevant folders and files are present. Confirm that the cmsgov-design-system release zip contains the dist folder.

    6. The next step is to run the lerna publish command for publish to NPM.

      yarn release

    7. Create a PR for the release branch titled after the release (i.e. Release 2.0.0). Merge the PR into master after the changes are approved.

  2. Create a release on GitHub

    1. Draft a new release on GitHub

    2. Tag the release with the newly created tag from the previous step (i.e. core-2.0.0).

    3. Title the release using the release number (i.e. 2.0.0)

    4. Attach the release zip created from the previous step (i.e. cmsgov-design-system-2.0.0.tgz) to the release as an asset

    5. Create sections for @cmsgov/design-system, @cmsgov/design-system-scripts and @cmsgov/design-system-docs using the subsections below.

      ## 🚨 Breaking/Behavioral changes
## 🚀 Added
## 💅 Changed
## 🛠 Fixed
## 📦 Internal
## 🚫 Deprecated

      Note: View commits since the last release by going to the releases page or by running: git log `git describe --tags --abbrev=0`..HEAD --oneline

    6. Review the release notes and publish

  3. Update the design.cms.gov documentation website

    1. Connect to CMS VPN cloudvpn.cms.gov.

    2. Log in to CBJ to Deploy the CMS Design System documentation website.

      Note: Your CBJ user will need to be a member of the wd-user group or you will be unable to see the linked job above.

    3. Select Build with Parameters on the side navigation menu.

    4. Enter the tag created in the first step (i.e. core-2.0.0) as the branch to deploy.

    Deploying the documentation website is a multi-stage pipeline that executes the deploy in two stages:

    • The first child job builds design-system, creates a tarball from the resulting artifacts, then uploads the tarball to S3.
    • The second child job downloads the tarball from S3, expands it onto the node Jenkins is using for the deploy, then copies the files to Netstorage via scp.

    Note: For a manual process: Visit the Documentation deploy process page in Confluence for these instructions.

Sketch Library Release Process

  1. Download the Sketch file from GitHub
  2. Update the CMSDS Sketch file locally with your changes
  3. Update the .xml file found in the design-assets folder in the following ways:
    • Update the item title with the version number
      • Example: CMS Design System UI kit - v1.1
    • Update pubDate using RFC822 format
      • Example: Mon, 13 Apr 2020 15:11:00
    • Update enclosure sparkle:version number
      • Example: sparkle:version="1.1"
  4. Create a PR with the updates to the .xml file and Sketch file
    • Add a title and short description for your changes.

Versioning

The design system follows the SemVer specification.

Semantic Versioning

Patch release

Bug fixes and other minor changes: Increment the last number, e.g. 1.0.1

Examples:

  • Backwards compatible Sass/JS bug fixes
  • Tiny visual changes to make the UI more consistent

Minor release

Backwards compatible new functionality, newly deprecated APIs, or substantial new functionality/improvements to private code: Increment the middle number, e.g. 1.1.0

Examples:

  • Addition of a new component
  • New classes, global variables, mixins, functions, or deprecated code
  • Minor visual changes to existing components

Major release

Changes which break backwards compatibility: Increment the first number, e.g. 2.0.0

Example changes:

  • Renamed or removed classes, mixins, functions, placeholders, or global variables.
  • Major visual changes to existing components