Update release guide

Signed-off-by: Volodymyr Kozieiev <vkjr.sp@gmail.com>
This commit is contained in:
Volodymyr Kozieiev 2021-05-06 12:49:51 +03:00
parent 0b8509949a
commit 8628cbbf76
No known key found for this signature in database
GPG Key ID: 82B04968DF4C0535
1 changed files with 38 additions and 33 deletions

View File

@ -1,51 +1,46 @@
# Description # Description
This document explains some of the steps that are involved in relseases. This document explains some of the steps that are involved in releases.
## PlayStore Metadata Updates
You can update Play Store releae metadata using `fastlane android upload_metadata`.
But that requires credentials necessary for accessing Play Store API. The simpler way is to edit files contained within [`fastlane/metadata`](metadata) and run the following CI job:
https://ci.status.im/job/status-react/job/tools/job/update-playstore-metadata/
# Release process # Release process
## Coordination ## Coordination
All the coordination is done in the #release channel on discord. All the coordination is done in the `#release` channel on discord.
## Using the script Release readiness can be tracked by watching an appropriate milestone at [milestones](https://github.com/status-im/status-react/milestones) section in github.
You can use the script to cut a release branch: When release is building you can check the progress in a testrail. Ask @churik for access if you don't have it
## Preparing branches
Special branches should be created at the start of a release process. That can be done manually or with the script
### Prepare branches with the script
You can use the script to cut a release branch. No arguments needed, the new release version will be deducted automatically:
`scripts/cut-release.sh` `scripts/cut-release.sh`
This will create a branch: Upon script call two branches will be created:
- `release/a.b.x`
- `chore/update-release-to-$version`
`release/a.b.x` The first one is the main release branch. All bugfixes should be cherry-picked from `develop` to it. Jenkins treats that branch specially and prepares release builds from it.
Create a branch: The second branch only updates the `VERSION` file and all you need to do is to merge it to `develop`. If you have the `gh` command installed, `cut-release` script will automatically create a PR for this.
`chore/update-release-to-$version` ### Prepare branches manually
And if you have the `gh` command installed, it will automatically create a PR for you. #### Create a branch
## Manual steps First, we need to create a release branch cut from develop.
The name of the branch should be `release/a.b.x` where `x` is actually `x`, not a variable, and `a` and `b` are the `MAJOR` and `MINOR` version of the app.
### Create a branch
First we need to create a release branch cut from develop.
The name of the branch should be `release/a.b.x` where `x` is actually `x`, not
a variable, and `a` and `b` are the `MAJOR` and `MINOR` version of the app.
For example, valid branch names are: For example, valid branch names are:
`release/1.12.x` or `release/3.12.x` `release/1.12.x` or `release/3.12.x`
#### Update version
### Update version
We need to update the `VERSION` file to reflect the release we want to build. We need to update the `VERSION` file to reflect the release we want to build.
@ -56,17 +51,18 @@ Jenkins will automatically build this branch and create release candidates.
Those will go through the QA process and the QA team will let us know when Those will go through the QA process and the QA team will let us know when
tested successfully. tested successfully.
## Bugfixes before app is released ## Bugfixes before an app is released
Because both `status-react` and `status-go` might have newer commits that we don't Because both `status-react` and `status-go` might have newer commits that we don't want to include, bug fixes should be applied separately to develop and the release branch.
want to include, bug fixes should be applied separately to develop and the release branch. The best workflow is to send a PR to develop, get it merged, and the cherry-pick on the
The best workflow is to send a PR to develop, get it merged and the cherry-pick on the
release branch. release branch.
If that's not practical for some reason (i.e develop has diverged significantly from release) It is a release manager's responsibility to cherry-pick bugfix from `develop` to release branch. In order to do this, you should be a part of a `release group` on github. Contact @jakubgs to be added.
If cherry-picking not practical for some reason (i.e develop has diverged significantly from release)
other workflows are possible. other workflows are possible.
In order to change status-go, a similar workflow applies. To change status-go, a similar workflow applies.
First checkout the tag used in `status-go-version.json`. First checkout the tag used in `status-go-version.json`.
Create a branch on status-go named: `release/vx.y.z+hotfix.w` where Create a branch on status-go named: `release/vx.y.z+hotfix.w` where
@ -99,8 +95,17 @@ And commit and push the changes
# Hotfix process # Hotfix process
The hotfix process is basically identical to the workflow above: The hotfix process is basically identical to the workflow of a bugfix:
1) Add the changes on status-react 1) Add the changes on status-react
2) Make sure you use a hotfix branch for status-go (unless we are happy to release from develop) 2) Make sure you use a hotfix branch for status-go (unless we are happy to release from develop)
3) Update the `VERSION` in status-react 3) Update the `VERSION` in status-react
# PlayStore Metadata Updates
This section is relevant only for the marketing team, no developer participation is required.
You can update Play Store release metadata using `fastlane android upload_metadata`.
But that requires credentials necessary for accessing Play Store API. The simpler way is to edit files contained within [`fastlane/metadata`](metadata) and run the following CI job:
https://ci.status.im/job/status-react/job/tools/job/update-playstore-metadata/