Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release 2.48.0 #5414

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

release 2.48.0 #5414

wants to merge 6 commits into from

Conversation

Roger-Ethyca
Copy link
Contributor

@Roger-Ethyca Roger-Ethyca commented Oct 23, 2024

Release Steps

We use GitHub’s release feature to tag releases that then get automatically deployed to DockerHub and PyPi via GitHub Actions. We also use a CHANGELOG.md to mitigate surprises to our users and help them plan updates accordingly. The release steps are as follows:

Major and Minor

  1. Open a PR that is titled the version of the release (i.e. 1.6.0)
    • Rename the Unreleased section of CHANGELOG.md to the new version number and put a date next to it
    • Update the compare links for both the new version and for the new Unreleased section
  2. Once approved, merge the PR
  3. Create a new release, ensuring that the last PR to get merged is the aforementioned CHANGELOG.md update PR
  4. Add the new version as the tag (i.e. 1.6.0)
  5. Make the title the version with a v in front of it (i.e. v1.6.0)
  6. Add a link to the CHANGELOG.md
  7. Auto-populate the release notes
  8. Publish the release

Patch

It may be necessary for a patch release to contain only select commits to the main branch since the last major or minor release. To create a release with only the desired changes, follow the steps below:

  1. Checkout the most recent release's tag

    1. To fetch the most recent tag's name, run:

      # fides on main
      git describe --abbrev=0 --tags
      
      #=> 1.2.3
    2. To checkout the most recent tag, run:

      #fides on main
      git checkout 1.2.3
      
      #=> Note: switching to '1.2.3'.
      #
      # You are in 'detached HEAD' state. You can look around, make experimental
      # changes and commit them, and you can discard any commits you make in this
      # state without impacting any branches by switching back to a branch.
      #
      # If you want to create a new branch to retain commits you create, you may
      # do so (now or later) by using -c with the switch command. Example:
      #
      # git switch -c <new-branch-name>
      #
      # Or undo this operation with:
      #
      # git switch -
      #
      # Turn off this advice by setting config variable advice.detachedHead to false
      #
      # HEAD is now at 0123abcd Commit Message

    !!! tip
    This can be combined into a single command:

     ```sh
     # fides on main
     git checkout $(git describe --abbrev=0 --tags)
    
     #=> Note: switching to '1.2.3'.
     #
     # You are in 'detached HEAD' state. You can look around, make experimental
     # changes and commit them, and you can discard any commits you make in this
     # state without impacting any branches by switching back to a branch.
     #
     # If you want to create a new branch to retain commits you create, you may
     # do so (now or later) by using -c with the switch command. Example:
     #
     # git switch -c <new-branch-name>
     #
     # Or undo this operation with:
     #
     # git switch -
     #
     # Turn off this advice by setting config variable advice.detachedHead to false
     #
     # HEAD is now at 0123abcd Commit Message
     ```
    
  2. Create a new branch from the HEAD commit of the most recent release's tag, called release-v<tag>

    # fides on tags/1.2.3
    git checkout -b release-v1.2.4
    
    #=> Switched to a new branch 'release-v1.2.4'
  3. If the changes to be included in the patch release are contained in one or more unmerged pull requests, change the base branch of the pull request(s) to the release branch created in the previous step

  4. Once approved, merge the pull request(s) into the release branch

  5. Create a new branch off of the release branch by running:

    # fides on release-v1.2.4
    git checkout -b prepare-release-v1.2.4
    
    #=> Switched to a new branch 'prepare-release-v1.2.4'
  6. Optional: Incorporate any additional specific changes required for the patch release by running:

    # fides on prepare-release-v1.2.4
    git cherry-pick <commit>...
  7. Copy the Unreleased section of CHANGELOG.md and paste above the release being patched

    1. Rename Unreleased to the new version number and put a date next to it
    2. Cut and paste the documented changes that are now included in the patch release to the correct section
    3. Commit these changes
  8. Open a pull request to incorporate any cherry-picked commits and the CHANGELOG.md changes into the release branch

    1. Set the base branch of this pull request to the release branch
    2. Once approved, merge the pull request into the release branch
  9. Create a new release from the release branch

    1. Add the new version as the tag (i.e. 1.2.4)
    2. Title the release with the version number, prefixed with a v (i.e. v1.2.4)
    3. Add a link to the CHANGELOG.md
    4. Auto-populate the release notes
  10. Publish the release

  11. Merge the new release tag into main

    !!! warning
    Pushing commits (including merge commits) to the main branch requires admin-level repository permissions.

    1. Checkout the main branch, and update the local repository:

      git checkout main
      #=> Switched to branch 'main'...
      
      git pull
    2. Merge the new release tag into main:

      git merge tags/1.2.4
    3. Handle any merge conflicts, and push to the remote main branch

Release Checklist

The release checklist is a manual set of checks done before each release to ensure functionality of the most critical components of the application. Some of these steps are redundant with automated tests, while others are only tested here as part of this check.

This checklist should be copy/pasted into the final pre-release PR, and checked off as you complete each step.

Additionally, there is a robust Release Process page available in Confluence (internal only).

Pre-Release Steps

General

From the release branch, confirm the following:

  • Quickstart works: nox -s quickstart (verify you can complete the interactive prompts from the command-line)
  • Test environment works: nox -s "fides_env(test)" (verify the admin UI on localhost:8080, privacy center on localhost:3001, CLI and webserver)
  • Have Roger run a QATouch automation run

Next, run the following checks via the test environment:

API

CLI

Run these from within the test environment shell:

  • git reset --hard - Note: This is required for the pull command to work
  • fides user login
  • fides push src/fides/data/sample_project/sample_resources/
  • fides pull src/fides/data/sample_project/sample_resources/
  • fides evaluate src/fides/data/sample_project/sample_resources/
  • fides generate dataset db --credentials-id app_postgres test.yml - Note: Because the filesystem isn't mounted, the new file will only show up within the container
  • fides scan dataset db --credentials-id app_postgres

Privacy Center

  • Every navigation button works
  • DSR submission succeeds
  • Consent request submission succeeds

Admin UI

  • Every navigation button works
  • DSR approval succeeds
  • DSR execution succeeds

User Permissions

  • Verify user creation
  • Verify a Viewer can view all systems
  • Verify a Data Steward can edit systems they are assigned

Documentation

  • Verify that the CHANGELOG is formatted correctly and clean up verbiage where needed
  • Verify that the CHANGELOG is representative of the actual changes

⚠️ Note that any updates that need to be made to the CHANGELOG should not be commited directly to the release branch.
Instead, they should be committed on a branch off of main and then PR'd and merged into main, before being cherry-picked
over to the release branch. This ensures that the CHANGELOG stays consistent between the release branch and main.

Publishing the release

When publishing the release, be sure to include the following sections in the release description:

  • ## Release Pull Request section that includes a link back to the release PR (i.e., this one!) for tracking purposes
  • ## QA Touch Test Run section that includes a link to the QATouch test run (QA team should provide this)

Post-Release Steps

Copy link

vercel bot commented Oct 23, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
fides-plus-nightly ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 24, 2024 8:32pm

Copy link

cypress bot commented Oct 23, 2024

fides    Run #10629

Run Properties:  status check passed Passed #10629  •  git commit e0b67b63d9: Submit form on Enter press (#5419)
Project fides
Branch Review release-2.48.0
Run status status check passed Passed #10629
Run duration 00m 40s
Commit git commit e0b67b63d9: Submit form on Enter press (#5419)
Committer Jason Gill
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 0
Tests that did not run due to a developer annotating a test with .skip  Pending 0
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 4
⚠️ You've recorded test results over your free plan limit.
Upgrade your plan to view test results.
View all changes introduced in this branch ↗︎

Copy link

cypress bot commented Oct 23, 2024

fides    Run #10615

Run Properties:  status check passed Passed #10615  •  git commit e4b525057f ℹ️: Merge 9651a5b46dc9bd42a1092dfdcbc95ca2213f4c15 into 29c9c46221d53484dfd3819e64db...
Project fides
Branch Review refs/pull/5414/merge
Run status status check passed Passed #10615
Run duration 00m 36s
Commit git commit e4b525057f ℹ️: Merge 9651a5b46dc9bd42a1092dfdcbc95ca2213f4c15 into 29c9c46221d53484dfd3819e64db...
Committer Roger Plotz
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 0
Tests that did not run due to a developer annotating a test with .skip  Pending 0
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 4
⚠️ You've recorded test results over your free plan limit.
Upgrade your plan to view test results.
View all changes introduced in this branch ↗︎

Copy link

codecov bot commented Oct 24, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.85%. Comparing base (4abb9e6) to head (9651a5b).
Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5414   +/-   ##
=======================================
  Coverage   83.84%   83.85%           
=======================================
  Files         382      382           
  Lines       24073    24071    -2     
  Branches     2624     2624           
=======================================
- Hits        20185    20184    -1     
+ Misses       3306     3305    -1     
  Partials      582      582           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants