Skip to content

Development principles

Jump to bottom
Daniel Silhavy edited this page Jan 4, 2023 · 8 revisions

Git Branching strategy

We are using a slightly modified version of Gitflow as a branching model. A detailed introduction to Gitflow can be found here.

Main branch

The main branch stores the official release history. The current version of the main branch always stores the latest release.

Development branch

The development branch serves as the integration branch for new feature and bugfix branches. It reflects the latest stable changes in the current development cycle.

Feature branches

Each new feature is implemented in a separate feature branch. Feature branches use development as their parent branch. When a feature is completed the respective branch gets merged back into development.

A feature branch is created the following way:

git checkout development
git checkout -b feature/newfeature

Release branches

Once the development branch has acquired enough features and bugfixes for a release, a release candidate branch is created based on the current version of the development branch. For details on the release procedure please refer to the release procedure documentation.

The release candidate always includes a version number and is created in the following way:

git checkout develop
git checkout -b RC-1.2.0

Once a release candidate is approved the respective branch is merged into the main branch.

Bugfix branches

Similar to feature branches, the bugfix branches are created directly from development. In contrast to hotfixes, bugfixes are not considered criticial and do not require a fast new release. Bugfix branches are created the following way:

git checkout development
git checkout -b bugfix/newbugfix

Hotfix branches

Hotfix branches are used to quickly patch production releases in case of critical errors. Hotfix branches are created directly from main and merged back into main and development as soon as they are completed. Once the hotfix is applied a new release shall be created.

git checkout main
git checkout -b hotfix/newhotfix

Pull requests

Once a feature or a hotfix branch is completed a new pull request against the development (in case of feature branches) or the main branch (in case of hotfix branches) is created:

  1. Navigate to the list of available branches. Depending on the concrete setup the new branch is available directly on the main repository or on your fork of the main repository.
Bildschirmfoto 2022-03-22 um 14 30 29
  1. Click on "New pull request"
Bildschirmfoto 2022-03-22 um 14 38 22
  1. Select the target (base) branch:
    • For feature branches select the development branch
    • For hotfix branches select the main branch
  2. Provide a summary of your changes in the textfield
  3. Click on "Create pull request"

Github Actions

We have several Github actions in place to handle various tasks of our CI/CD chain:

Automatic deployment

Once the developmentbranch or the master branch are updated, a new version of the DASH-IF Conformance Software is automatically deployed on our server. We are using different URLs to map to the different branches of the Conformance Software:

The scripts that trigger the deployment can be found in the .github/workflows folder of the project

Linting

Changes to the development branch are automatically validated in terms of the code quality. The corresponding linting workflow can be found in .github/workflows

API documentation

Changes to the developmentbranch trigger a workflow to update the Doxygen documentation. Internally, the Doxygen workflow pushes the latest changes of the documentation to the gh-pages branch of the project. Github uses the files located in this branch as the input for the hosted version of the documentation that can be found at http://dashif.org/DASH-IF-Conformance/.

Clone this wiki locally