Skip to content

Latest commit

 

History

History
53 lines (31 loc) · 3.8 KB

before-publishing-a-release.md

File metadata and controls

53 lines (31 loc) · 3.8 KB

Tasks before publishing a new release of GOV.UK Frontend

When preparing to publish a release of GOV.UK Frontend we need to ensure we are following proper procedure to effectively track our work and are prepared to publish our new release.

Kick off the release

The whole team should coordinate whether to publish a new release. Choose a team member to lead on the release, typically a developer.

We next need to define a cutoff date for this release. Once the cutoff date passes, do not add any further major changes. We can still add small fixes before we publish as long as we notify the team. However, we should try to avoid adding too many fixes in this way, as it requires us to have to repeat steps of the release process.

Raise an issue for the release

Use the '🚀 Release' issue template to create an issue in the govuk-frontend repository tracking the tasks for this release.

The template lists the main tasks that happen for every release. If the release at hand needs some specific steps, make sure to add items to the lists for each of them, especially:

This issue should be:

Draft comms and release notes for the community

A content designer and/or tech writer should do the following:

  • write announcements for slack posts, email and to go on the design system website after we release GOV.UK Frontend (for example, draft comms for the cookie banner component)
  • check who the release’s contributors are and if we have consent to include their name

A technical writer should finalise draft of release notes. Release notes will require a 2i review by another technical writer, make sure the technical writer has time to coordinate this. When ready, open a pull request to update the CHANGELOG.md file with the updated release notes.

If the technical writer is unavailable, ask for help in the gds-technical-writing Slack channel or confer with a content designer.

The team should also post a message on any relevant issue discussions with rationale for any decisions we've made.

Finalise the release

At this stage, the person leading the release should agree the publishing date. Once the team agrees, this confirms a code and content freeze. Use the #design-system-team-channel to confirm sign-off from:

  • content designer, technical writer and designers for guidance, examples and community backlog decision rationale
  • technical writer and developers for Nunjucks macros
  • developers for changes to GOV.UK Frontend
  • technical writer for release notes
  • content designer, community manager and technical writer for announcements and engagement activities

Make sure access tokens are up to date

Before each release, we need to make sure our access tokens are up to date.

  1. Sign into the govuk-patterns-and-tools npm account and follow the instructions in the team's password management tool to check and/or update the access token.
  2. Sign into the govuk-design-system-ci GitHub account and follow the instructions in the team's password management tool to check and/or update the access token.