Scenario 1: Simple release process

1. During the first week of work, user stories A, B, and C are implemented.
2. Three corresponding Hutte features are created, with changes committed for each. Pull Requests (also referred to as Merge Requests) are created and merged into the main branch.
3. The person in charge for deployments/releases (Release Manager) navigates to the “Releases” tab in Hutte and creates a draft release, naming it “1.0.”
4. In the Release view, the end user can see the Git history, which represents the three features merged into the main branch.
5. The release (even in Draft status) can then be deployed to any sandbox in the release pipeline for QA and UAT testing. Note that production deployment is not possible while the release is in Draft status. This is intentional, as only a Published release, with fixed and tested content, can be deployed to Production.
6. After completing the necessary QA activities, the Release Manager clicks “Publish Release,” and then clicks “Deploy” again to start the production deployment.

Scenario 2: QA Testing Identifies Bugs in the Release

1. Assumed that in step 5 of Scenario 1, QA identifies bugs in some user stories.
2. A new feature, “User Story D,” is created in Hutte to address the bug fixes.
3. Changes are made within this feature, and once verified by the developer in the development sandbox, a Pull Request is created and merged into the main branch.
4. After merging the bugfix from “User Story D” into the main branch, it automatically appears in the “1.0” release, which is still in Draft status. The updated release can then be deployed to QA/UAT for further testing.
5. (Repeat steps 5 and 6 from the Scenario 1)

Scenario 3: One or More Features Need to Be Excluded From the Release

Examples for Excluding User Stories

1. Excluding the Most Recently Merged User Stories
   • If user stories A, B, and C were merged in the order A → B → C, and you need to exclude C, or both B and C:
     • This is straightforward since Hutte allows you to cut off a release at an earlier commit.
     • For example, you can release A (excluding B and C) or release A and B (excluding C).
2. Excluding a User Story Merged Earlier or in the Middle
   • If user stories A, B, and C were merged in the order A → B → C, and you need to exclude B or A:
     • In this case, you need to perform a “revert” of the Hutte feature you wish to exclude. The revert action undoes the changes made by that feature.
     • Hutte provides a “Revert” button next to each merge commit within the release module. Clicking this button automates the creation of a new Hutte feature (e.g., “Feature X”) that reverts the changes of the selected feature.
     • After creating the revert feature, follow the same workflow as in Scenario 2, ensuring that the revert is tested in QA to confirm it doesn’t break any other functionality.

<aside>

Key considerations for feature reverts

• The revert feature must also go through QA testing to ensure it integrates seamlessly without introducing new issues.
• Hutte simplifies the revert process with automated feature creation, but testing remains essential to maintain release quality. </aside>