website-and-documentation/content/en/docs-old/v1/concepts/3_use-cases/_index.md

62 lines
2 KiB
Markdown
Raw Normal View History

---
title: Use Cases
weight: 2
description: The golden paths in the engineers and product development domain
---
test: configure comprehensive markdown linting with Docsy best practices Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials).
2025-10-23 14:25:46 +02:00
## Rationale
The challenge of IPCEI-CIS Developer Framework is to provide value for DTAG customers, and more specifically: for Developers of DTAG customers.
That's why we need verifications - or test use cases - for the Developer Framework to develop.
![alt text](platforms-def.drawio.png)
(source: https://tag-app-delivery.cncf.io/whitepapers/platforms/)
2024-08-05 13:21:06 +00:00
## Golden Paths as Use Cases
* https://platformengineering.org/blog/how-to-pave-golden-paths-that-actually-go-somewhere
* https://thenewstack.io/using-an-internal-developer-portal-for-golden-paths/
* https://nl.devoteam.com/expert-view/building-golden-paths-with-internal-developer-platforms/
* https://www.redhat.com/en/blog/designing-golden-paths
## List of Use Cases
Here we have a collection of possible usage scenarios.
### Socksshop
Deploy and develop the famous socks shops:
* https://medium.com/@wadecharley703/socks-shop-microservices-application-deployment-on-the-cloud-cd1017cce1c0
2024-08-05 13:21:06 +00:00
* See also mkdev fork: https://github.com/mkdev-me/microservices-demo
2024-08-05 13:21:06 +00:00
### Humanitec Demos
* https://github.com/poc-template-org/node-js-sample
### Github Examples
2024-08-30 13:53:02 +02:00
* https://github.com/kezoo/nestjs-reactjs-graphql-typescript-boilerplate-example
### Telemetry Use Case with respect to the Fibonacci workload
The Fibonacci App on the cluster can be accessed on the path https://cnoe.localtest.me/fibonacci.
It can be called for example by using the URL https://cnoe.localtest.me/fibonacci?number=5000000.
The resulting ressource spike can be observed one the Grafana dashboard "Kubernetes / Compute Resources / Cluster".
The resulting visualization should look similar like this:
![alt text](fibonacci-app_cpu-spike.png)
2024-08-30 13:53:02 +02:00
## When and how to use the developer framework?
### e.g. an example
.... taken from https://cloud.google.com/blog/products/application-development/common-myths-about-platform-engineering?hl=en
test: configure comprehensive markdown linting with Docsy best practices Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials).
2025-10-23 14:25:46 +02:00
![alt text](image.png)