sheppy/opendesk
1
0
Fork 0
mirror of https://gitlab.opencode.de/bmi/opendesk/deployment/opendesk.git synced 2025-12-06 07:21:36 +01:00
Code Issues Packages Projects Releases Wiki Activity

fix(docs): Update workflow.md.

Browse Source
This commit is contained in:
Thorsten Roßner
2024-07-24 09:51:08 +02:00
parent 6b609edc4a
commit fd3df7df67
2 changed files with 32 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/getting-started.md
View File

@@ -3,7 +3,7 @@ SPDX-FileCopyrightText: 2023 Bundesministerium des Innern und für Heimat, PG Ze
SPDX-License-Identifier: Apache-2.0 SPDX-License-Identifier: Apache-2.0
--> -->
<h1>Getting stated</h1> <h1>Getting started</h1>
This documentation should enable you to create your own evaluation instance of openDesk on your Kubernetes cluster. This documentation should enable you to create your own evaluation instance of openDesk on your Kubernetes cluster.

80
docs/workflow.md
View File

@@ -22,8 +22,8 @@ SPDX-License-Identifier: Apache-2.0
* [Branch workflows](#branch-workflows) * [Branch workflows](#branch-workflows)
* [`main`](#main) * [`main`](#main)
* [`develop`](#develop) * [`develop`](#develop)
* [`docu`](#docu) * [`docs`](#docs)
* [`mntn`](#mntn) * [`fix`](#fix)
* [`feat`](#feat) * [`feat`](#feat)
* [Branch names](#branch-names) * [Branch names](#branch-names)
* [Commit messages / Conventional Commits](#commit-messages--conventional-commits) * [Commit messages / Conventional Commits](#commit-messages--conventional-commits)
@@ -169,8 +169,8 @@ The basic facts for the flow are:
- Developers can create sub-branches from their feature branch(es) as needed. - Developers can create sub-branches from their feature branch(es) as needed.
- When a *feature* branch gets pushed a Merge Request in `Draft` state is automatically created. - When a *feature* branch gets pushed a Merge Request in `Draft` state is automatically created.
- We know three types of *feature* branches: - We know three types of *feature* branches:
- `docu`: Doing just documentation changes - `docs`: Doing just documentation changes
- `mntn`: Maintenance of the openDesk software components and minor configurational changes - `fix`: Maintenance of the openDesk software components and minor configurational changes
- `feat`: All changes that do not fall into the two categories above, especially - `feat`: All changes that do not fall into the two categories above, especially
- supplier deliverables and - supplier deliverables and
- configurational changes that have a significant impact on openDesk users or require migrations[^1] - configurational changes that have a significant impact on openDesk users or require migrations[^1]
@@ -185,21 +185,21 @@ gitGraph
checkout "develop" checkout "develop"
commit id: "QA 'nightly develop'" commit id: "QA 'nightly develop'"
commit id: " " commit id: " "
branch "docu" branch "docs"
checkout "docu" checkout "docs"
commit id: "Documentation commits" type: HIGHLIGHT commit id: "Documentation commits" type: HIGHLIGHT
checkout "develop" checkout "develop"
merge "docu" merge "docs"
checkout "main" checkout "main"
merge "develop" tag: "No release" merge "develop" tag: "No release"
checkout "develop" checkout "develop"
commit id: " " commit id: " "
branch "mntn" branch "fix"
checkout "mntn" checkout "fix"
commit id: "Maintenance commits" type: HIGHLIGHT commit id: "Maintenance commits" type: HIGHLIGHT
commit id: "QG 'mntn'" type: REVERSE commit id: "QG 'fix'" type: REVERSE
checkout "develop" checkout "develop"
merge "mntn" merge "fix"
commit id: "QA 'release merge'" type: REVERSE commit id: "QA 'release merge'" type: REVERSE
checkout "main" checkout "main"
merge "develop" tag: "Patch or minor release" merge "develop" tag: "Patch or minor release"
@@ -231,7 +231,7 @@ The Standard Quality Gate addresses quality assurance steps that should be execu
1. Linting 1. Linting
- Blocking - Blocking
- Licensing: [reuse](https://github.com/fsfe/reuse-tool) - Licensing: [reuse](https://github.com/fsfe/reuse-tool)
- openDesk specific: Especially `images.yaml` and `charts.yaml`, find more details in the [development](./development.md) docu - openDesk specific: Especially `images.yaml` and `charts.yaml`, find more details in [development.md](./development.md).
- Non Blocking - Non Blocking
- Security: [Kyverno policy check](../.kyverno) addressing some IT-Grundschutz requirements - Security: [Kyverno policy check](../.kyverno) addressing some IT-Grundschutz requirements
- Formal: Yaml - Formal: Yaml
@@ -277,8 +277,8 @@ This section will explain the workflow for each branch (type) based on the Gitfl
- `QA 'nightly main'`: Execute the SQG based on the most recent release. The upgrade test environment should be a long-standing environment that only gets built from scratch with the previous technical release when something breaks the environment. - `QA 'nightly main'`: Execute the SQG based on the most recent release. The upgrade test environment should be a long-standing environment that only gets built from scratch with the previous technical release when something breaks the environment.
- Merge points: We are using the [Semantic Release convention](https://github.com/semantic-release/semantic-release) which itself is based on the [Semantic Versioning (SemVer) notation](https://semver.org) to automatically create technical releases on the merge points. - Merge points: We are using the [Semantic Release convention](https://github.com/semantic-release/semantic-release) which itself is based on the [Semantic Versioning (SemVer) notation](https://semver.org) to automatically create technical releases on the merge points.
- "No release": When a merge from `develop` includes only changes from `docu` branches the merge into `main` will only consist of `docs` or `chore` commits. No new release will be generated by that merge. - "No release": When a merge from `develop` includes only changes from `docs` branches the merge into `main` will only consist of `docs` or `chore` commits. No new release will be generated by that merge.
- "Patch or minor release": When changes from `mntn` branches get merged these might contain `fix` or `feat` commits causing a new technical release to be built with an updated version on Patch or Minor level. - "Patch or minor release": When changes from `fix` branches get merged these might contain `fix` or `feat` commits causing a new technical release to be built with an updated version on Patch or Minor level.
- "Minor or major release": When changes from `feat` branches get merged these might contain `feat` commits even with breaking changes, causing a technical release to be built with an updated version on Minor or Major level. - "Minor or major release": When changes from `feat` branches get merged these might contain `feat` commits even with breaking changes, causing a technical release to be built with an updated version on Minor or Major level.
- "Manual Functional Release Activities": Technical releases are loosely coupled to functional releases. The additional activities for a functional release select an existing technical release as a basis to generate the artifacts required for a functional release, for example: - "Manual Functional Release Activities": Technical releases are loosely coupled to functional releases. The additional activities for a functional release select an existing technical release as a basis to generate the artifacts required for a functional release, for example:
- Conduct additional manual explorative and regression tests. - Conduct additional manual explorative and regression tests.
@@ -289,19 +289,19 @@ This section will explain the workflow for each branch (type) based on the Gitfl
- `QA 'nightly develop'`: Follows the same approach as `QA 'nightly main'` - execute the SQG based in this case on the head revision of the `develop` branch. - `QA 'nightly develop'`: Follows the same approach as `QA 'nightly main'` - execute the SQG based in this case on the head revision of the `develop` branch.
- `QA 'release merge'`: The Merge Request for this merge has to be created manually by members of the platform development team. It should document: - `QA 'release merge'`: The Merge Request for this merge has to be created manually by members of the platform development team. It should document:
- That the SQG was successfully executed upon the to-be merged state - it could be done explicitly or based on a `QA 'nightly develop'` - That the SQG was successfully executed upon the to-be merged state - it could be done explicitly or based on a `QA 'nightly develop'`
- In case of `mntn` changes that usually how no test automation: Changes have been verified by a member of the platform development team. - In case of `fix` changes that usually how no test automation: Changes have been verified by a member of the platform development team.
- That the changes have been reviewed by at least two members of the platform development team giving their approval on the Merge Request. - That the changes have been reviewed by at least two members of the platform development team giving their approval on the Merge Request.
- Merge points (from `docu`, `mntn`, and `feat` branches): No additional activity on these merge points as the QA is ensured before the merge in the just-named branch types. - Merge points (from `docs`, `fix`, and `feat` branches): No additional activity on these merge points as the QA is ensured before the merge in the just-named branch types.
##### `docu` ##### `docs`
Branches of type `docu` only contain the commits themselves and have to adhere to the workflow basic fact that: Branches of type `docs` only contain the commits themselves and have to adhere to the workflow basic fact that:
> All merges into `develop` or `main` require two approvals from the platform development team. > All merges into `develop` or `main` require two approvals from the platform development team.
##### `mntn` ##### `fix`
Besides the actual changes being committed in an `mntn` branch there is only the: Besides the actual changes being committed in an `fix` branch there is only the:
- `QG 'mntn'`: In addition to validating the actual change the owner of the branch has to ensure the successful execution of the SQG. - `QG 'fix'`: In addition to validating the actual change the owner of the branch has to ensure the successful execution of the SQG.
##### `feat` ##### `feat`
@@ -318,47 +318,29 @@ This branch type requires the most activities on top of the actual development:
#### Branch names #### Branch names
Branches created from the `develop` branch have to adhere to the following notation: `<party[-developer]>/<type>/<component>/<details>`: Branches created from the `develop` branch have to adhere to the following notation: `<type>/<responsible_developer>/<details>`:
- `<party[-developer]>`: An identifier for the developing party optionally plus the name of the developer or team working on that branch. The following two-letter shorthand notations should be used for the owner: - `<type>`: From the list of branch types explained above:
- Suppliers - `docs`
- `co`: Collabora - `fix`
- `cp`: CryptPad
- `el`: Element
- `nc`: Nextcloud
- `nd`: Nordeck
- `op`: OpenProject
- `ox`: Open-Xchange
- `uv`: Univention
- `xw`: XWiki
- Other
- `pd`: (openDesk) Platform Development
- `xx`: Other, not one of the parties mentioned before
- `<type>`: Based on the branch types described in this document valid values for type are
- `docu`
- `mntn`
- `feat` - `feat`
- `<responsible_developer>`: Something that makes you identifiable as owner of the branch, e.g. the first letter of your first name followed by your family name.
- `<component>`: Valid components are - `<details>`: A very short note about what is going to happen in the branch and ideally what component is affected from the following list of components:
- `helmfile` - `helmfile`
- `ci` - `ci`
- `cross-functional`
- `docs` - `docs`
- `collabora` - `collabora`
- `cryptpad` - `cryptpad`
- `element` - `element`
- `jitsi` - `jitsi`
- `nextcloud` - `nextcloud`
- `nubus`
- `open-xchange` - `open-xchange`
- `openproject` - `openproject`
- `services` - `services`
- `univention-management-stack`
- `xwiki` - `xwiki`
- `<details>`: A very short note about what is going to happen in the branch Example: `feat/tmueller/bump_nextcloud_to_29.0.0`.
Example: `pd-tom/fix/open-xchange/bump_to_8.76`.
**Note**: The above naming convention is not enforced yet, but please ensure you make use of it. **Note**: The above naming convention is not enforced yet, but please ensure you make use of it.
@@ -367,7 +349,7 @@ Example: `pd-tom/fix/open-xchange/bump_to_8.76`.
Commit messages must adhere to the [Conventional Commit standard](https://www.conventionalcommits.org/en/v1.0.0/#summary). Commits that do not adhere to the standard get rejected by either [Gitlab push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) or the CI. Commit messages must adhere to the [Conventional Commit standard](https://www.conventionalcommits.org/en/v1.0.0/#summary). Commits that do not adhere to the standard get rejected by either [Gitlab push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html) or the CI.
```text ```text
<type>(<scope>): [path/to/issue#1] <short summary> <type>(<scope>): [path/to/issue#1] <short summary>.
│ │ │ │ │ │ │ │
│ │ | └─> Summary in present tense, sentence case, with no period at the end │ │ | └─> Summary in present tense, sentence case, with no period at the end
│ │ | │ │ |
@@ -378,7 +360,7 @@ Commit messages must adhere to the [Conventional Commit standard](https://www.co
└─> Commit Type: chore, ci, docs, feat, fix └─> Commit Type: chore, ci, docs, feat, fix
``` ```
Example: `fix(univention-management-stack): Update standard session timeout of openDesk realm in Keycloak` Example: `fix(open-xchange): Bump to 8.26 to heal issue with functional mailbox provisioning.`
**Beware**: The commit messages are an essential part of the [technical releases](https://gitlab.opencode.de/bmi/opendesk/deployment/sovereign-workplace/-/releases) as the release's notes are generated from the messages. **Beware**: The commit messages are an essential part of the [technical releases](https://gitlab.opencode.de/bmi/opendesk/deployment/sovereign-workplace/-/releases) as the release's notes are generated from the messages.