Add DRIs for release testing (#6804)
- Add DRIs for release testing - Add DRIs for patch release testing - Update patch release playbook
This commit is contained in:
Noah Talerman
@@ -103,36 +103,30 @@ Note: Please prefix versions with `fleet-v` (e.g., `fleet-v4.0.0`) in git tags,
|
||||
|
||||
### Patch releases
|
||||
|
||||
Generally, a patch should be released when bugs or performance issues are identified that prevent
|
||||
users from getting their job done with Fleet.
|
||||
A patch is released when an issue with the current stable release falls under the following criteria:
|
||||
- Security concerns
|
||||
- Previously stable features are unusable/broken
|
||||
- New features are unusable/broken
|
||||
|
||||
Any issue that meets the patch release criteria is sent to the [DRI for release testing/QA](https://fleetdm.com/handbook/product#rituals).
|
||||
|
||||
#### Process
|
||||
|
||||
##### The easy way
|
||||
1. The DRI for release testing/QA notifies the [directly responsible individual (DRI) for creating the patch release branch](https://fleetdm.com/handbook/engineering#rituals) to create the new branch, starting from the git tag of the prior release. Patch branches should be prefixed with `patch-`. In this example we are creating `4.3.1`:
|
||||
|
||||
If all commits on `main` are acceptable for a patch (no high-risk changes, new features, etc.), then
|
||||
the process is easy. Just follow the regular release process as described above, incrementing
|
||||
only the patch (`major.minor.patch`) of the version number. In this scenario, there is no need to
|
||||
perform any of the steps below.
|
||||
|
||||
##### The hard way
|
||||
|
||||
When only some of the newer changes in `main` are acceptable for release, a separate patch branch
|
||||
must be created and relevant changes cherry-picked onto that branch:
|
||||
|
||||
1. Create the new branch, starting from the git tag of the prior release. Patch branches should be
|
||||
prefixed with `patch-`. In this example we are creating `4.3.1`:
|
||||
```
|
||||
git checkout fleet-v4.3.0
|
||||
git checkout --branch patch-fleet-v4.3.1
|
||||
```
|
||||
|
||||
2. Cherry pick the necessary commits into the new branch:
|
||||
2. The DRI for creating the patch release branch cherry picks the necessary commits into the new branch:
|
||||
|
||||
```
|
||||
git cherry-pick d34db33f
|
||||
```
|
||||
|
||||
3. Push the branch to github.com/fleetdm/fleet:
|
||||
3. The DRI for creating the patch release branch pushes the branch to github.com/fleetdm/fleet:
|
||||
|
||||
```
|
||||
git push origin patch-fleet-v4.3.1
|
||||
```
|
||||
@@ -141,21 +135,17 @@ must be created and relevant changes cherry-picked onto that branch:
|
||||
Action](https://github.com/fleetdm/fleet/actions/workflows/goreleaser-snapshot-fleet.yaml) will
|
||||
be invoked to push a container image for QA with `fleetctl preview` (eg. `fleetctl preview --tag patch-fleet-v4.3.1`).
|
||||
|
||||
4. Check in the GitHub UI that Actions ran successfully for this branch and perform [QA smoke
|
||||
testing](https://github.com/fleetdm/fleet/blob/main/.github/ISSUE_TEMPLATE/smoke-tests.md).
|
||||
4. The DRI for creating the patch release branch checks in the GitHub UI that Actions ran successfully for this branch.
|
||||
|
||||
5. Follow the standard release instructions at the top of this document. Be sure that modifications
|
||||
to the changelog and config files are commited _on the `patch-*` branch_. When the patch has been
|
||||
released, return to finish the following steps.
|
||||
5. The DRI for creating the patch release branch notifies the [DRI for release testing/QA](https://fleetdm.com/handbook/product#rituals) that the branch is available for completing [smoke tests](https://github.com/fleetdm/fleet/blob/main/.github/ISSUE_TEMPLATE/smoke-tests.md).
|
||||
|
||||
6. Cherry-pick the commit containing the changelog updates into a new branch, and merge that commit
|
||||
into `main` through a Pull Request.
|
||||
6. The DRI for release testing/QA makes sure the standard release instructions at the top of this document are followed. Be sure that modifications to the changelog and config files are commited _on the `patch-*` branch_.
|
||||
|
||||
7. **Important!** Manually check the database migrations. Any migrations that are not cherry-picked in a
|
||||
patch must have a _higher_ timestamp than migrations that were cherry-picked. If there
|
||||
are new migrations that were not cherry-picked, verify that those migrations have higher
|
||||
timestamps. If they do not, submit a new Pull Request to increase the timestamps and ensure that
|
||||
migrations are run in the appropriate order.
|
||||
7. The DRI for release testing/QA notifies the [DRI for the release ritual](https://fleetdm.com/handbook/engineering#rituals) that the patch release is ready. The DRI for the release ritual releases the patch.
|
||||
|
||||
8. The DRI for creating the patch release branch cherry-picks the commit containing the changelog updates into a new branch, and merges that commit into `main` through a Pull Request.
|
||||
|
||||
9. **Important!** The DRI for creating the patch release branch manually checks the database migrations. Any migrations that are not cherry-picked in a patch must have a _later_ timestamp than migrations that were cherry-picked. If there are new migrations that were not cherry-picked, verify that those migrations have later timestamps. If they do not, submit a new Pull Request to increase the timestamps and ensure that migrations are run in the appropriate order.
|
||||
|
||||
TODO [#2850](https://github.com/fleetdm/fleet/issues/2850): Improve docs/tooling for this.
|
||||
|
||||
|
||||
@@ -314,6 +314,7 @@ The following rituals are engaged in by the directly responsible individual (DR
|
||||
| Engineering group discussions | Weekly | See "Group Weeklies". | Zach Wasserman |
|
||||
| On-call handoff | Weekly | Hand off the on-call engineering responsibilities to the next on-call engineer. | Zach Wasserman |
|
||||
| Release ritual | Every three weeks | Go through the process of releasing the next iteration of Fleet. | Zach Wasserman |
|
||||
| Create patch release branch | Every patch release | Go through the process of creating a patch release branch, cherry picking commits, and pushing the branch to github.com/fleetdm/fleet. | Luke Heath |
|
||||
|
||||
## Slack channels
|
||||
|
||||
|
||||
@@ -531,6 +531,8 @@ Directly Responsible Individuals (DRI) engage in the ritual(s) below at the freq
|
||||
| ✨ Product design review | Weekly (Thursdays) | The Product team discusses "ready for review" items and makes the decision on whether the UI changes are ready for engineering specification and later implementation. | Noah Talerman |
|
||||
| 👀 Product review | Every three weeks | Fleeties present features and improvements in the upcoming release. A discussion is held about bugs, fixes and changes to be made prior to release. | Noah Talerman |
|
||||
| Product office hours doc prep | Weekly | Every week a backup doc is created to accompany the Product office hours event | Reed Haynes |
|
||||
| Release testing/QA | Every three weeks | Every release cycle, by end of day Wednesday of release week, all issues move to "Ready for release" on the 🚀Release board. | Reed Haynes |
|
||||
| Release testing/QA report | Every three weeks | Every release cycle, on the Monday of release week, the (DRI for the release ritual)[https://fleetdm.com/handbook/engineering#rituals] is updated on status of testing. | Reed Haynes |
|
||||
|
||||
|
||||
## Slack channels
|
||||
|
||||
Reference in New Issue
Block a user