Current branch management for release process subject to change once the core repositories have been merged:
You may need to release the BisAppSettings repo together with the backend and frontend if any PRs since the last release required BisAppSettings changes
Create a release branch off of the latest develop branch. This should be done in all repos that you want to release, typically the backend and frontend. The release branch name should be the same for both the frontend and backend (e.g. release-31-01-2021) to allow the e2e tests to run against the release backend branch
Create a PR into master for each repo that needs releasing. Wait until the backend Github actions have completed before creating the frontend PR: this will let the e2e tests run against the backend image built from the release branch
On push to master github-tag-and-release workflow will trigger this will:
Automatically generate a Semantic Version number based on commits (see the contribution guide)
Generate release notes that can be found in the release pages of the repositories
After merging your PR, create a separate PR in the docker-orchestration repo to increase the version Backendnumbers in the prod Kubernetes config
Merge in the docker-orchestration PR and run the prod deploy jobs on the Jenkins ProposalSubmission tab to release the new version
For a hotfix create a branch directly off of master instead and create the PR into master. You must remember to merge this change back into develop.