add Relase and Deployment decision documentation

doc/deployment_process.md

+# Manual Triggering of Release Pipeline in GitLab
+
+-   Status: Draft
+-   Date: 2024-08-26
+
+Technical Story:
+https://gitlab.opencode.de/opencode-analyzer/management/-/issues/94
+
+## Context and Problem Statement
+
+Our current deployment process is not clearly defined, including the
+requirements that must be met to deploy a release to development or
+production. This gap increases the risk of deploying unreviewed or
+potentially harmful changes, impacting system stability and user
+experience. We need a deployment process that integrates with our
+existing GitLab infrastructure, supports our requirements, and provides
+flexibility to accommodate last-minute changes or withhold releases
+based on emerging issues.
+
+## Considered Options
+
+-   Automated Deployment Upon Commit/Merge/Release: While ensuring fast
+    and consistent delivery of features and fixes, there is less control
+    and higher risk of deploying potentially harmful changes.
+-   Scheduled deployments: Provides predictability, but eliminates
+    flexibility and does not add value to our current structure and
+    working style.
+
+## Decision Outcome
+
+We have decided to adopt manual triggering of the release pipeline in
+GitLab for deploying changes to development and production. This
+increases control over what gets deployed and when. This minimizes the
+risk of errors and disruptions in our development process and for end
+users.
+
+### Consequences
+
+-   Enhanced Control where deployments can be timed to suit our needs in
+    development and reducing the risk of impact on users.
+-   Changes undergo thorough scrutiny before deployment, increasing the
+    reliability of our development and production environment.
+-   Flexibility that allows the team to respond to last-minute findings
+    or external factors that may require a delay or modification of
+    deployment.
+-   Initial setup involves modifying existing CI/CD scripts to
+    incorporate deployment paths for development and production,
+    including:
+    -   Definition of steps required (e.g. passing the test suite)
+    -   Preparing the environment for deployment via pipelines

doc/release_process.md

+# Implementation of Semantic Versioning and Git Tagging for Release Management
+
+-   Status: Draft
+-   Date: 2024-08-26
+
+Technical Story:
+https://gitlab.opencode.de/opencode-analyzer/management/-/issues/94
+
+## Context and Problem Statement
+
+Our current release management process lacks a standardized method for
+versioning and tracking changes across releases, making release
+identification hard. This impacts our ability to efficiently manage and
+rollback releases and complicates communication about changes and
+features included in each release. Further, it complicates compatibility
+tracking between components (mainly `DatProvider` and `dashboard`).
+
+## Considered Options
+
+-   Calendar Versioning (CalVer): Calendar Versioning is a convention
+    based on dates for release versioning used by popular projects like
+    Ubuntu. However, there is no clear reason to use it in our context
+    based on ("When to use
+    CalVer")\[https://calver.org/#when-to-use-calver\].
+-   Continuous Releases based on commit IDs: Using commit id's for
+    release management is a viable path on rapidly changing projects
+    with the ambition to be able to roll-out any and every commit.
+    However, in our context we prefer more control over the release
+    process and compatibility between the components.
+
+## Decision Outcome
+
+We will adopt Semantic Versioning for our software releases and use Git
+tagging to mark these releases in our version control system. This
+approach will standardize our release process, providing clear,
+version-controlled, and easily identifiable releases.
+
+### Consequences
+
+-   Introduces a systematic approach to versioning that is widely
+    recognized and understood.
+-   Facilitates easier tracking of features, fixes, and breaking changes
+    across releases.
+-   Enhances rollback capabilities by providing clear rollback targets.
+-   Requires training and discipline to ensure all team members follow
+    the release guidelines consistently.
+-   Initial setup involves modifying existing CI/CD scripts to
+    incorporate versioning and tagging steps, based on current research
+    steps include:
+    -   Introducing a VERSION file in the repository.
+    -   Selecting and implementing a tool to bump major/minor/patch
+        versions predictably.
+    -   Selecting and implementing a tool to generate release notes
+        based on commits.
+    -   Modification of existing software and build process to include
+        the version from the VERSION file on API route or in the
+        frontend.