Introduction

The development and release process is supported by a structured process with the code organized in a number of GitHub repositories (see Project Structure).

A dedicated decision was taken to keep the code organized in a parent repository with independent submodules, where the parent mainly carries the documentation for all repositories. This structure allows deploying frontend and backend independently, while, e.g., issues can be exchanged between the repositories.

The server-setup repository runs on a single branch (development) and is not versioned, as it maintains only the ansible code. Feature branches can/should be created for major changes

The repositories carrying the developed code for frontend and backend (Strapi) use two branches, development and production, where quite obviously development carries the complete development history with all commits.

The production branch is used to deploy new versions as releases. During the release process the development branch is merged into the production branch using the git --squash option. This produces a single commit in the production branch, skipping all intermittent commits of the development branch. With this the development branch carries the complete commit history, whereas the production branch has only commits when releases were published.

In order to keep the release information and commit structure well organized it is aspired to:

• create an issue for every requested/required change, split in sub issues where necessary
• create a commit for every issue solved, allowing e.g. cherry-picking of releases
• create a release referencing all issues resolved within it

INFO

Release Template

### 🎉 New Functionality

### ⏫ Enhancements

### 🐛 Bugfixes

### 🔥 Breaking Changes

### 🏁 To-do after Release

### 📚 Documentation

A loose versioning rule is used differentiating Functional Releases (adding new functionality) and Patch Releases (combining a number of bug fixes minor enhancements) and more or less urgent Hot Fixes (bug fixes on production). For Hot Fixes are represented by a single commit in development and production branch in parallel