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.
![# Copyright (c) 2010 - 2025, Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.
# All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this
# list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
# this list of conditions and the following disclaimer in the documentation
# and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its
# contributors may be used to endorse or promote products derived from
# this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# We kindly request you to use one or more of the following phrases to refer to
# foxBMS in your hardware, software, documentation or advertising materials:
#
# - "This product uses parts of foxBMS®"
# - "This product includes parts of foxBMS®"
# - "This product is derived from foxBMS®"
digraph G {
compound=true;
subgraph cluster_0 {
style=filled;
color=lightgrey;
node [style=filled,color=white];
a0 [group=1, label="Developer"];
a1 [group=2, label="Reviewer"];
a0->a1 [style=invis];
label = "";
}
subgraph cluster_1 {
style=filled;
color=lightgrey;
node [style=filled,color=white];
b0 [group=1, label="Bare Repository"];
b1 [group=2, label="CI"];
b2 [group=3, label="Change Request"];
b0 -> b1 [label="Triggers"];
b1 -> b2 [label="Feedback"];
b2 -> b0[label="If approved\nmerge to\nmaster branch", color=darkgreen, fontcolor=darkgreen];
label = "Git Server";
}
subgraph cluster_2 {
style=filled;
color=lightgrey;
node [style=filled,color=white];
c0 [group=1, label="Local Repository"];
c1 [group=2,label="Build"];
c2 [group=2,label="Test"];
c3 [group=2,label="Guidelines"];
c4 [group=3, label=<<font color='white'>Success Matrix</font>>, fillcolor="darkgreen:red"];
c0 -> c1[label="Trigger"];
c0 -> c2[label="Trigger"];
c0 -> c3[label="Trigger"];
c1 -> c4[label=<<font color='darkgreen'>Success</font><br/>or<br/><font color='red'>Failure</font>>];
c2 -> c4[label=<<font color='darkgreen'>Success</font><br/>or<br/><font color='red'>Failure</font>>];
c3 -> c4[label=<<font color='darkgreen'>Success</font><br/>or<br/><font color='red'>Failure</font>>];
label = "Build Server";
}
a0 -> b0 [label="Commits to\nfeature branch"];
b1 -> a0 [label="Feedback"];
b1 -> a1 [label="Feedback"];
a0 -> b2 [label="Request"];
a1 -> b2 [label="if ok\napprove", fontcolor="darkgreen", color="darkgreen"];
a1 -> b2 [label="if not ok\nreject", fontcolor="red", color="red"];
b1 -> c0[ltail=cluster_2];
c4 -> b2[label="If success\napprove CR", color="darkgreen", fontcolor="darkgreen"];
c4 -> b2[label="If failure\nblock CR", color="red", fontcolor="red"];
d [label="truncate feature branch"]
b2 -> d [label="If rejected", color="red", fontcolor=red];
}](../../_images/graphviz-8e331bec6497bee0af42a5e10c741730e7587e93.png)
Fig. 3.13 foxBMS 2 software development process
