3.1. Software Development Process

The main goal of the development process is to ensure that only well tested code is committed to the master branch. This can either be a new feature to extend the capabilities of the existing implementation or changes that remove a bug in the existing implementation. For the sake of simplicity these changes are summarized under the terms of Change Request (for details see here).

The starting point of all work done, is an issue describing a bug in the current implementation or a feature that is missing or needs to be extended. Based on this issue a so called feature branch is created (the name is the same whether it is bug or feature) by a developer working on the related issue. This feature branch is pushed to the main (bare) repository managed by some Git server. The Git server triggers the CI pipeline. This pipeline manages several build servers that then run different integration tasks (jobs) (building the binary, testing and checking for guideline violations). The output of a build server is a success matrix based on the run jobs. The status of the test is shown in the Change Request. In parallel the changes that would be introduced to the master branch are reviewed by developers (developers that did not work on the feature branch) and comments to the changes are added as needed.

The first requirement for a feature branch getting merged into the master branch is the success of the CI pipeline and the second requirement is the approval of the reviewer. If one of both is missing merging the feature branch is rejected.

This development process is shown in Fig. 3.13.

Fig. 3.13 foxBMS 2 software development process