Skip to content

Release Checklist

Jump to bottom
Mirac Kara edited this page Dec 14, 2023 · 35 revisions

Release Checklist

It is important to perform the following steps as a pair so there are two brains watching each step, since there is the potential for a misstep that can be messy to correct after the fact. We also have a policy of not releasing on Friday to avoid missing post-release problems over the weekend.

Checklist Steps

  1. Draft proposed release notes for product manager to review and revise. Use e-mail, IM, a GitHub PR, anything to let them know they need to review and acknowledge. Be sure to check which will be the oldest supported agent release and update the release notes to mention that.

  2. Is the agent ready for release?

    • agent and new functionality has been tested against production, staging, and the EU. This can be done quickly by using the test-regions tool in GitHub Enterprise.
      • Production and Staging and EU or (alternative EU account are recommended)
      • be sure to save notes somewhere of the results of this testing, this way we can go back and review it later if there is an issue with the release
      • example program runs and displays data in the UI
    • go test -bench=. ./... - benchmarks do not show regressions
    • Be sure to include -race to detect potential race conditions.
    • Make sure to update the GUIDE.md, README.md, and docs.newrelic.com for the work you've done.
    • Ensure that any releases of integration packages are noted in the CHANGELOG.md (to avoid running into issues like this one

  3. Create, review, and merge a commit into the develop branch with these version changes:

    • Change the version in version.go
    • Add a new section header to the top of CHANGELOG.md
    • Go over the release notes with the PM.
    • Verify that the indirects in go.mod files are automatically filtered out before the final commit, after all tests have completed.

  4. Open a pull request from the develop branch into master

    • Use this format for the name: "Release 3.14.1"
    • Ensure that the tests all pass
    • Merge the PR into master

  5. Once the version change has been merged, tag the commit with the prefix "v"

    • Example: git tag v1.0.0 9191db2
    • If a new integration package was release or if one was updated, tag it as well: git tag v3/integrations/nrelasticsearch-v7/v1.0.0
      • You can check which integrations need to be released with a git command like this: git diff --name-only v3.1.0... | grep -v test

  6. Push the release tag

    • Example: git push --tags

  7. Check all of the links in the changelog and godocs. While they should all have been tested if possible before, some links can't be tested until you have published to GitHub.

    • If you find broken links, DO NOT just update the links & change commit that the release tag points to - this will break the checksum for the release. Instead, you will need to do a new release with the fixes.

  8. Add the release notes to the GitHub release. Go to Releases > Draft a new release, put in the release notes, and mark it with the tag for the release.

  9. Add the release notes to the New Relic documentation site:

    • find or check out the docs-website repository.

    • copy the previous version's release notes file to a new file. You'll see the files in /src/content/docs/release-notes/agent-release-notes/go-release-notes/. Name it appropriately. For example, to release the v3.13.0 agent, copy the go-agent-3-12-0.mdx file to a new go-agent-3-13-0.mdx file.

    • edit the new file, changing the version number in the metadata at the top, and replacing the content below with the new Release Notes markdown text. Make sure to add any feature/bug/security related changes to the metadata at the top as well in the following format. Strings in each category should be a brief 1-2 sentence summary of the changes implemented for the release.

      • features: ["Feature 1", "Feature 2"]
      • bugs: []
      • security: ["Security Update 1"]

    • The EOL policy page is now automated.

    • Commit changes to a new branch and make a PR:

      • git co -b go-agent-release-v<version_number>
      • git add <the_new_file>
      • git commit -m "Release notes for Go Agent v<version_number>"
      • git push <your remote> go-agent-release-v<version_number>
      • Open up a new PR using the browser link that git provides. Follow the instructions given to you in the Documentation team's PR template.

    • NOTE! Github relative links won't work on the docs site, so check the links!

    • Contact the #help-documentation @hero to release these docs.

  10. Send an email to [email protected] with the release notes and the release number. Copy the GitHub's HTML that it produced from your markdown version to facilitate easy pasting.

    • NOTE! Github relative links won't work on in the email!

  11. Close all public PRs that have just been released!

  12. Update Angler to include the new supportability metric for the newly released version of the agent.

    • Have someone on our team approve your PR, then merge it yourself.

  13. Announce the release in #go-agent and #gts-go Slack room to accrue all the emojis. Copy the GitHub's HTML that it produced from your markdown version to facilitate easy pasting.

Post-Release Activities

  1. Communicate bug fixes and new features to the customers who have requested them. Go through support tickets, GitHub Issues, etc. and let people know to try the new agent to fix their troubles. Make sure your Product Manager does this too -- they may have work to do regarding this as well.

  2. Ensure that any documentation changes have made it to pkg.go.dev. If you perform a go mod download, pkg.go.dev will see this and attempt to refresh its cache of godocs.

  3. Monitor use of the new agent using the Go Agent Angler dashboard.

Clone this wiki locally