Front end release management

This is our official process for releasing new versions of code-gov-front-end.

Table of contents

1. Principles
2. Versioning
3. Release process
   1. Git workflow
   2. Publishing a new release

Principles

1. Follow well-established versioning practices
2. Provide detailed notes for each release
3. Encourage contributions and thank contributors for their hard work

Versioning

See Version Control for more information about semantic versioning and what constitutes a release

Release process

Git workflow

See Git Workflow for more information about how to create new branches and suggest changes to @code.gov/* repositories

Publishing a new release

⚠️ In these docs, {{ version }} should always be replaced with the semantic version number, i.e. 1.2.1 ⚠️

Create the release branch

• Determine if the version is a patch (#.#.#), minor (#.#.0), or major (#.0.0) version

• Branch off master and use the branch name format release-{{ version }}:

         git pull origin master
         git checkout -b release-{{ version }} origin/master
  

Example > git checkout -b release-0.0.7 origin/master

---

This is being refactored because of new Federalist release packaging. Updates coming soon! In order to deploy, the .env file will need to be edited to include the API key for production branch and/or staging.

Get started

• Close all running processes in the terminal.
• Publish new versions of any other components that have changed. If any other components listed at the top of Component Release Management have changed since the last release of code-gov-front-end, follow the instructions in Component Release Management to publish new versions to npm and update the package.json of code-gov-front-end with the new version numbers.
• If you haven't created a branch for this release in code-gov-front-end yet, create the branch following the branching instructions for releases
• In code-gov-front-end, run npm run update-data. This will copy the new versions of repos.json and tasks.json that were just generated (as well as the schema.json) from the code-gov-data remote repository into your local code-gov-front-end repository. Run git status to see what change were made. If there were changes, then commit those changes to the release branch.
• Run npm install to download the new components. Commit any changes.

---

Test the release

Test all of the latest updates and release to master.

• Follow the testing instructions to test the branch. Merge changes into master.
• After master passes all tests, create a PR and merge into staging. (Note: Master should be the most recent code for the site.)
• When Federalist is done building the site on staging, you can view the updates to staging.
• Visit staging to verify any changes you made.
• When satisfied with changes on staging, create a PR from master to production.

Deploy the release

• Push the version branch up to GitHub
• Merge release-{{ version }} back in to the master branch
• Run git checkout master and git pull origin master to update your local repository
• Merge Master into Production to release to https://code.gov.
• Check that all test's passed for new release's site (e.g., Federalist, Circle, Snyk)

---

Create the release in GitHub

• In GitHub releases select the release draft notes you had previously started or Draft a new release. Use the template provided from the wiki.
• Add the tag: v{{ version }}
• Use target: master
• Add release notes to the body
• Have at least one team member review the release notes
• Select Publish release

---

Publicize the release

• Post a message in the #code-gov-team Slack channel linking to the release.
• Post a message in the #code-gov-partners Slack channel linking to the release. Pin the message to the channel.
• Post a message to the code@gsa.gov listserv.

---

Setup the next draft release notes

• Click "Draft a new release" from the Releases page
• Set the target to master
• Add the title [unreleased]
• Save draft

---