-
Notifications
You must be signed in to change notification settings - Fork 27
Development principles
We are using a slightly modified version of Gitflow as a branching model. A detailed introduction to Gitflow can be found here.
The main branch stores the official release history. The current version of the main branch always stores the latest release.
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.
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
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.
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 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
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:
- 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](https://user-images.githubusercontent.com/2427039/159494521-b5566dfc-0809-48a8-bc0e-071a69ec29ce.png)
- Click on "New pull request"
![Bildschirmfoto 2022-03-22 um 14 38 22](https://user-images.githubusercontent.com/2427039/159494412-57e45c2a-2e5d-4cb4-bb8c-dc45d14b82b6.png)
- Select the target (base) branch:
- For feature branches select the development branch
- For hotfix branches select the main branch
- Provide a summary of your changes in the textfield
- Click on "Create pull request"
We have several Github actions in place to handle various tasks of our CI/CD chain:
Once the development
branch 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:
-
https://conformance.dashif.org/
- currently hosts the non-refactored version of the Conformance Software. Once we reached a stable version with the new code this URL will reflect the latest stable version released on Github
-
https://beta.conformance.dashif.org/
- new, refactored version of the installation automatically deployed/updated once the
master
branch is updated
- new, refactored version of the installation automatically deployed/updated once the
-
https://staging.conformance.dashif.org/
- new, refactored version of the installation automatically deployed/updated once the
development
branch is updated
- new, refactored version of the installation automatically deployed/updated once the
The scripts that trigger the deployment can be found in the .github/workflows
folder of the project
Changes to the development
branch are automatically validated in terms of the code quality. The corresponding linting workflow can be found in .github/workflows
Changes to the development
branch 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/.