1
0
mirror of https://github.com/nttgin/BGPalerter.git synced 2024-05-19 06:50:08 +00:00

improved git flow doc structure

This commit is contained in:
Massimo Candela
2020-04-17 21:02:29 +02:00
parent 6c1c744e36
commit 413c193ebf
2 changed files with 17 additions and 16 deletions

View File

@@ -58,5 +58,6 @@ Read the documentation below for more options.
- [Notification user groups](docs/usergroups.md)
- [More information for developers](docs/develop.md)
- [All npm commands](docs/develop.md#all-npm-commands)
- [Git flow](docs/release-process.md#git-flow)
- [Report context](docs/context.md)
- [Release process](docs/release-process.md)

View File

@@ -46,22 +46,6 @@ Minor releases are anyway tested and deployed for the monitoring of our network.
A minor release can also be released as a part of the normal release cycle in case there are no new features to justify a major release.
## Git flow
1) The development happens in the `dev` branch.
2) When a set of feature is defined as the next release candidate, the `dev` branch is branched to create the `release` branch which contains the release candidate code.
3) The release candidate is tested as described above.
4) After the test period, the release candidate is promoted to pre-release:
1) The source is tagged with a tag reporting the release number
2) It is compiled and released in the [release tab](https://github.com/nttgin/BGPalerter/releases)
5) The pre-release is tested
6) After the test period, the pre-released is marked as latest and released as stable.
1) Clients will be notified of the new release.
7) The `release` branch is merged in `master` and after deleted.
All pull requests must happen against the `dev` branch (or rebased during review). If needed they will be cherry-picked in the `release` branch.
### Dependencies
We use [Dependabot](https://dependabot.com/) to automatically check for newer version of the dependencies used by BGPalerter.
The dependencies used are listed in [package.json](https://github.com/nttgin/BGPalerter/blob/dev/package.json).
@@ -81,3 +65,19 @@ We currently use the following automation on the repository:
* [Hound](https://houndci.com/) to check code correctness and style.
* [Snyk](https://snyk.io/) to check for vulnerabilities in pull requests.
* [GitHub Security Alerts](https://github.com/nttgin/BGPalerter/network/alerts) to check for vulnerabilities on the entire repository.
# Git flow
1) The development happens in the `dev` branch.
2) When a set of feature is defined as the next release candidate, the `dev` branch is branched to create the `release` branch which contains the release candidate code.
3) The release candidate is tested as described above.
4) After the test period, the release candidate is promoted to pre-release:
1) The source is tagged with a tag reporting the release number
2) It is compiled and released in the [release tab](https://github.com/nttgin/BGPalerter/releases)
5) The pre-release is tested
6) After the test period, the pre-released is marked as latest and released as stable.
1) Clients will be notified of the new release.
7) The `release` branch is merged in `master` and after deleted.
All pull requests must happen against the `dev` branch (or rebased during review). If needed they will be cherry-picked in the `release` branch.