Release process

Release process

The purpose of this section to describe the standardized release process and provide a guide for those who are new to this task. Next, we detail the individual steps required to produce a release.

1. Create release candidate: After each pull request is made to the develop branch of the repository, a new release candidate is generated. Once the release candidate build is available, a full suite of (automated?) functional test cases are run. After running the test cases there will be two possible outcomes:

2. Test pass successfully: 100% percent pass rate, at which point we can continue with the process and generates the staging version.

3. At least 1 test failed: If the failure was due to a regression in the test case, then the QA member will fix the test and submit a pull request to generate a new release candidate. If the failure was due to a regression in the product, then the QA member will enter a bug. Once this bug has been fixed by a developer, a new release candidate will be generated.

4. Create a staging version of the application: once the release candidate was tested successfully, we proceed to generate a staging version (a version that uses the resources from production but is only available internally, the client still doesn’t have access to this version). This version will run the same functional test as the release candidate. After running the test cases there will be two possible outcomes:

   1. Test pass successfully: 100% percent pass rate, after this we can continue with the process, and we will continue with the QA Approve

   2. At least 1 test failed: if the regression is in the test the QA members should fix and send another pull request to solve that issue and generate another release candidate, in case if the regression is related to the application the QA will add this issue as a bug and will be assigned to a developer, the developer will fix the issue and create another pull request to generate another release candidate.

5. QA Approval: The QA Team will review the staging version to evaluate scenarios that are not being covered by the functional test. If they find any issues that they might considered a showstopper bug, they will add the issue to the backlog and refuse the release. Once the bug has been fixed and a new staging release candidate has been produced, QA will validate that no showstopper bugs are present and will then approve the Staging release. It’s important to highlight that some bugs can be found, but if the bug doesn’t enter in the showstopper category the release process can proceed.

6. Sign-Off request: The Product Owner of the team should create an email to let the stakeholders know that the product is ready for release but pending to approval. The email should contain the URL to download the staging version, also should contain the release notes explaining the major changes in functionality, if it’s necessary it should also include which bugs were fixed. There are two outcomes after creating the Sign-off request:

   1. Stakeholders refuse to sign off the release to production because they find some issues with the staging version, those issues will be included as showstoppers bugs to solve them ASAP, once those bugs are being fixed the entire process should start again from the creation of the release candidate

   2. Stakeholders approve the staging release candidate, once this approval is giving by all stakeholders the team can proceed releasing the staging version into production

Diagram Description automatically generated