We use BGPalerter in production to monitor our network.
It's essential for us to make sure BGPalerter is reliable and secure. As it is essential for us, it is also essential for the many organizations that are currently relying on BGPalerter for their monitoring.
For this reason, we want to summarize in this document our efforts in this matter.
The image below shows the flow for releasing a new version of BGPalerter
## Release candidate
A release candidate is not a release at all, and so it will not appear in the [release tab](https://github.com/nttgin/BGPalerter/releases), it will not have a release number, and its testing is ongoing.
A release candidate is a way for us to identify the set of features that are mature enough to be included in the next release.
We compile the release candidate and we use it to monitor our network. We do this while running in parallel the previous stable release of BGPalerter.
This not only assures us to have at least a stable monitoring running, but also allows us to compare the two versions in terms of resource utilization and reported alerts.
We do such testing for at least 1 week (but in general, especially in busy periods, this lasts more, and we leave it running for up to 4 weeks).
Additionally, we have continuous testing in place and we test the release candidate against the entire data flow generated by [RIPE RIS](https://ris.ripe.net) for the entire v4 and v6 address spaces (6k+ BGP updates per second).
* The first number identifies a major release. The first number is incremented only when there are breaking changes which cannot be addressed with deprecation warnings and sensible defaults.
* The second number identifies a minor release. The second number is incremented if new functionalities are introduced.
* The third number identifies a patch. The third number is incremented when there are changes which don't introduce any new functionality but improve/repair the available ones.
In the event a serious bug (e.g., affecting one of the core functionalities) is discovered in a released version, we will not follow the timing described above and release as soon as possible a patch.
Patches are anyway tested and deployed for the monitoring of our network.
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).
It is important to distinguish between the dependencies used for development and the one used for production. Only production dependencies are bundled in the binary of a release.
### Module isolation
BGPalerter includes a series of components (i.e. connectors, monitors, reports) each of them are enabled from config.yml.
All components are bundled in the binary release, BUT they are loaded (and so also their dependencies) only if enabled from the config file.
If a component is not enabled from the config file, the component file is not loaded and the code not executed.
### Automation
We currently use the following automation on the repository:
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.
