feat: add Developer Hub documentation

.github/workflows/deploy-gh-pages.yaml

@@ -0,0 +1,41 @@
+name: Deploy GH Pages
+on:
+  push:
+    branches:
+      - main
+      - feature/developer-hub
+    paths:
+      - 'mkdocs.yml'
+      - 'docs/**'
+
+permissions:
+  contents: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Setup Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: 3.x
+
+      - name: Set cache id
+        run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV
+
+      - name: Use cache
+        uses: actions/cache@v3
+        with:
+          key: mkdocs-material-${{ env.cache_id }}
+          path: .cache
+          restore-keys: |
+            mkdocs-material-
+
+      - name: Install mkdocs-material and plugins
+        run: pip install mkdocs-material
+
+      - name: Deploy to GH Pages
+        run: mkdocs gh-deploy --force

Taskfile.yaml

@@ -0,0 +1,7 @@
+version: 3
+
+tasks:
+  serve:
+    desc: Run local dev server
+    cmds:
+      - docker run --rm -it -p 8000:8000 -v ${PWD}:/docs squidfunk/mkdocs-material

docs/Guidelines/PDG_0_-_Changelog & Drafts/index.md

@@ -0,0 +1,5 @@
+# Changelog of Pmoscode Developer Guidelines (PDGs)
+
+| Created     | Post-History                                                                                 |
+|-------------|----------------------------------------------------------------------------------------------|
+| 01-Sep-2023 | Initial contribution                                                                         |

docs/Guidelines/PDG_0_-_Changelog & Drafts/trg-0-template.md

@@ -0,0 +1,18 @@
+# PDG 0.1 - Templates
+
+This is the template for new PDG's.
+
+| Status     | Created      | Post-History                               |
+|------------|--------------|--------------------------------------------|
+| Deprecated | 05-May-2023  | Deprecated it because obsolete or outdated |
+| Active     | 27-Feb-2023  | Mark active without limitations            |
+| Draft      | 13-Sept-2022 | Initial contribution                       |
+
+## Why
+
+Here you will find the purpose of this PDG. For example, because it makes it much easier for others to use, or it's a default style convention, ...
+
+## Description
+
+Here you will find the description of the PDG. 
+Provides best practices: In the best case with code example or/and step-by-step guide.

docs/Guidelines/PDG_1_-_Documentation/pdg-1-1.md

@@ -0,0 +1,21 @@
+# PDG 1.1 - README.md
+
+| Status | Created     | Post-History |
+|--------|-------------|--------------|
+| Active | 01-Sep-2023 |              |
+
+## Why
+
+A good written `README.md` file is the entry point for everyone visiting a repository. It should contain all necessary information.
+
+## Description
+
+Each repository **must** contain a `README.md` file which **shall** cover the following topics:
+
+- A short introduction to the software component it offers
+- Basic description of the repository and its content
+- Installation instructions to get component working
+- If required, additional post-installation configuration steps to finish installation
+- Optional: Development / contribution instructions 
+
+If installation instructions are too comprehensive for the `README.md`, move content to `INSTALL.md` file and reference it here. See [PDG 1.2](pdg-1-2.md).

docs/Guidelines/PDG_1_-_Documentation/pdg-1-2.md

@@ -0,0 +1,15 @@
+# PDG 1.2 - INSTALL.md
+
+| Status | Created      | Post-History |
+|--------|--------------|--------------|
+| Active | 01-Sep-2023  |              |
+
+## Why
+
+When a repository contains code which needs to be configured/setup or installed, the `README.md` file should cover this information. 
+If this is too much content, it can be moved into a `INSTALL.md` file and referenced in the README.md.
+
+## Description
+
+Create a `INSTALL.md` file in the main folder of the repository and add all installation relevant information.
+Also add all post-installation configuration steps to finish installation.

docs/Guidelines/PDG_1_-_Documentation/pdg-1-3.md

@@ -0,0 +1,19 @@
+# PDG 1.3 - CHANGELOG.md
+
+| Status | Created     | Post-History |
+|--------|-------------|--------------|
+| Active | 01-Sep-2023 |              |
+
+## Why
+
+Knowing of what changes have been made is very important. Getting information about features, bug and security fixes are mandatory. 
+
+This helps everyone who is using the software to understand what version to choose or when to upgrade.
+
+## Description
+
+To track changes of releases a `CHANGELOG.md` **must** exist in repositories. The format **should** follow the [Keep A Changelog](https://keepachangelog.com/en/1.0.0/).
+
+The versioning of releases **must** follow [semantic versioning](https://semver.org/).
+
+For easy changelog creation, [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) **should** be applied to every commit.

docs/Guidelines/PDG_2_-_GIT/pdg-2-1.md

@@ -0,0 +1,13 @@
+# PDG 2.1 - Default Branch
+
+| Status | Created     | Post-History |
+|--------|-------------|--------------|
+| Active | 22-Dec-2023 |              |
+
+## Why
+
+This is a personal decision. But future features or requirements could demand on it. E.g.: for security scanning.
+
+## Description
+
+Default branch **must** be `main`.

docs/Guidelines/PDG_2_-_GIT/pdg-2-2.md

@@ -0,0 +1,49 @@
+# PDG 2.3 - Repo structure
+
+
+| Status | Created     | Post-History |
+|--------|-------------|--------------|
+| Active | 22-Dec-2023 |              |
+
+## Why
+
+To have a unified and common repository structure is helpful when working in more than one project. It can be adapted but should remain consistent.
+
+## Description
+
+All repositories **must** contain the following files and folders:
+
+```text
+CONTRIBUTING.md
+LICENSE
+README.md
+CODE_OF_CONDUCT.md
+```
+
+**Optional** files and folders:
+
+```text 
+AUTHORS.md
+INSTALL.md
+SECURITY.md
+```
+
+### Files
+
+#### README.md
+
+Your repository **must** contain a `README.md` file. See [PDG 1.1 - README.md](../PDG_1_-_Documentation/PDG-1-1).
+
+#### INSTALL.md
+
+Your repository **should** contain a `INSTALL.md` file. See[PDG 1.2 - INSTALL.md](../PDG_1_-_Documentation/PDG-1-2).
+
+#### Legal documentation
+
+For the following files, see [PDG 7.01](../PDG_7_-_Open_Source_Governance/PDG-7-1)
+
+- AUTHORS.md (optional)
+- CODE_OF_CONDUCT.md
+- CONTRIBUTING.md
+- LICENSE
+- SECURITY.md

docs/Guidelines/PDG_3_-_Kubernetes/trg-3-1.md

@@ -0,0 +1,49 @@
+---
+title: PDG 3.01 Superseded Supported Versions
+---
+
+| Status     | Created      | Post-History         |
+|------------|--------------|----------------------|
+| Superseded | 08-Mar-2023  | Marked as superseded |
+| Moved      | 02-Jan-2023  | content moved        |
+| Draft      | 13-Sept-2022 | n/a                  |
+
+## Superseded by PDG 5.09 - Helm test
+
+This is superseded by [PDG 5.09 - Helm test](../PDG%205%20-%20Helm/PDG-5-09)
+
+## ~~Description~~
+
+~~As new Kubernetes versions are released every few months, teams need to support 3 versions at a time:~~
+
+- latest
+- latest - 1
+- latest - 2
+
+~~For checking the current versions available please use the [AKS Kubernetes release calendar](https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-kubernetes-release-calendar). The __AKS GA__ column is relevant and determines which is the Azure release date of a Kubernetes version. Example: at 02-Jan-2023 the current AKS GA version is 1.25, therefore the supported versions are 1.25, 1.24 and 1.23.~~
+
+## ~~Testing compatibility~~
+
+~~For testing whether the application is compatible with the supported Kubernetes versions CI/CD pipeline integration or local deployment is recommended. For local deployment please see [Kind](https://kind.sigs.k8s.io/) clusters where a Kubernetes cluster can be started with a [specific version](https://kind.sigs.k8s.io/docs/user/configuration/#kubernetes-version) locally on a development machine. Example for example:~~
+
+```yaml
+# config.yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+- role: control-plane
+- role: worker
+  image: kindest/node:v1.25.3@sha256:f1de3b0670462f43280114eccceab8bf1b9576d2afe0582f8f74529da6fd0365
+```
+
+~~After Kind is installed locally, run the following command with the config above:~~
+
+```sh
+kind create cluster --config=config.yaml
+```
+
+~~A Kubernetes node will start with version 1.25.~~
+
+## ~~Why~~
+
+~~New Kubernetes minor versions are released quite frequently with bugfixes, security patches and new features. Clusters implement these new versions at a different pace but the applications that are deployed there has to be supported.~~

docs/Guidelines/PDG_3_-_Kubernetes/trg-3-2.md

@@ -0,0 +1,54 @@
+---
+title: PDG 3.02 - Persist Data
+---
+
+| Status | Created     | Post-History    |
+|--------|-------------|-----------------|
+| Draft  | 17-Jul-2023 | 'loos' typo fix |
+| Active | 07-Mar-2023 |                 |
+| Draft  | 02-Jan-2023 | n/a             |
+| Moved  | 02-Jan-2023 | content moved   |
+
+## Why
+
+In cases where data has to be persisted (database, uploaded files etc.), Kubernetes **must** be configured to create Persistent Volume that is attached to an storage created by a storage provider, where data remains even after the deletion of the application. Otherwise, an incidental deletion will delete all state.
+
+## Description
+
+Using stateful data requires additional caution to not lose data by accident. Therefore, when a pod/deployment/statefulset resource is removed, data will still be available on the StorageClass's disk that was used.
+
+## How
+
+Example PersistentVolumeClaim:
+
+```yaml
+# pvc.yaml
+kind: PersistentVolumeClaim
+apiVersion: v1
+metadata:
+  name: pvc-persistent-tmp-demo
+spec:
+  accessModes:
+    - ReadWriteOnce
+  resources:
+    requests:
+      storage: 50Mi
+```
+
+This can be referenced in the volumes section of a Pod/Deployment/StatefulSet resource:
+
+```yaml
+# deployment.yaml
+#...
+      volumes:
+        - name: pv-tmp-demo
+          persistentVolumeClaim:
+            claimName: pvc-persistent-tmp-demo
+#...
+```
+
+:::tip
+
+It is not recommended to directly request the claim in a StatefulSet! Rather create the PVC separately and reference that as an existing claim. See the example in [Bitnami's Postgresql chart](https://github.com/bitnami/charts/tree/main/bitnami/postgresql) where an existing claim can be referenced for the primary database at the [primary.persistence.existingClaim property](https://github.com/bitnami/charts/tree/main/bitnami/postgresql#postgresql-primary-parameters).
+
+:::