diff --git a/docs/Contributing/Releasing-Fleet.md b/docs/Contributing/Releasing-Fleet.md index 1d5338a5d2..54d3ab7773 100644 --- a/docs/Contributing/Releasing-Fleet.md +++ b/docs/Contributing/Releasing-Fleet.md @@ -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. diff --git a/handbook/engineering/README.md b/handbook/engineering/README.md index e437e2e8b3..82a362da0c 100644 --- a/handbook/engineering/README.md +++ b/handbook/engineering/README.md @@ -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 diff --git a/handbook/product/README.md b/handbook/product/README.md index 39426252c0..410f5cc95f 100644 --- a/handbook/product/README.md +++ b/handbook/product/README.md @@ -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