refactor(project): folders for streams and activities

content/en/blog/news/240823-archsession/240823-archsession.md

@@ -37,3 +37,4 @@ weight: 20
 ### Workflow / CI/CD
 
 * https://cnoe.io/blog/optimizing-data-quality-in-dev-portals
+

content/en/docs/procedure/_index.md

@@ -1,31 +0,0 @@
-+++
-archetype = "chapter"
-title = "Project"
-weight = 5
-[params]
-    author = 'stephan.lo@telekom.de'
-    date = '2024-08-01'
-+++
-
-## Next steps
-
-1. propose and run developer use cases (e.g. a typescript microservice, a react frontend, a golang api)
-2. fill in the individual platform reference architecture
-3. implement the arch as MVP, drive the use cases from 1.
-
-
-### possible Customizations:
-1. bebauungsplan referenzarchitektur
-2. templates / golden paths
-3. platform orchestrator
-
-
-## Vorgehen:
-
-* in 2 wochen grobe skizze - bestandteile, auswahl
-* skill & ressourcenplan
-* abstimmung mit verträgen
-
-#### Issues
-
-* Cloud-Continuum, Multicloud

content/en/docs/project/streams/_index.md

@@ -1,15 +1,17 @@
 ---
-title: Streams
+title: Workstreams
 weight: 1
 ---
 
-This page is WiP. Stefan and Stephan try to solve the mission 'wir wollen losmachen'.
+This page is WiP (23.8.2024). 
 
-Idea: 
+Stefan and Stephan try to solve the mission 'wir wollen losmachen'.
 
-1. First we define a rough overall structure (see 'streams') and propose some initial activities (like user stories) within them.
+**Solution Idea**: 
-1. Next we work in iterative steps and produce iteratively progress and knoeledge and outcomes in these activities.
+
-1. Next the whole team decides which are the next valuable steps
+1. First we define a **rough overall structure (see 'streams')** and propose some initial **activities** (like user stories) within them.
+1. Next we work in **iterative steps** and produce iteratively progress and knowledge and outcomes in these activities.
+1. Next the **whole team** decides which are the next valuable steps
 
 ## Overall Structure: Streams
 
@@ -19,46 +21,14 @@ We discovered three **streams** in the first project steps (see also [blog](../.
 1. POCs (Applications, Platform-variants, ...)
 1. Deployment, production-lifecycle
 
-## Proposal of Activities aka User Stories in the streams
+```markmap
-
+# 
-
+## Stream 'Fundamentals'
-
+### Platform-Definition
-### Stream 'Research'
+### CI/CD Definition
-
+## Stream 'POC'
-#### Activity 'Platform-Defintion'
+### CNOE
-
+### SIA Asset
-#### Activity 'CI/CD Defintion'
+## Stream 'Deployment'
-
+### Forgejo
-##### Rationale
+```
-
-In Gitops basierten Plattformen (Anm.: wie es zB. CNOE und Humanitec mit ArgoCD sind) trifft das klassische Verständnis von Pipelining mit finalem Pushing des fertigen Builds auf die Target-Plattform nicht mehr zu.
-
-D.h. in diesem fall is Argo CD = Continuous Delivery = Pulling des desired state auf die Target plattform. Eine pipeline hat hier keien Rechte mehr, single source of truth ist das 'Control-Git'. 
-
-D.h. es stellen sich zwei Fragen:
-1. Wie sieht der adaptierte Workflow aus, der die 'Single Source of Truth' im 'Control-Git' definiert? Was ist das gewünschte korrekte Wording? Was bedeuen CI und CD in diesem (neuen) Kontext ? Auf welchen Environmants laufen Steps (zB Funktionstest), die eben nicht mehr auf einer gitops-kontrollierten Stage laufen?
-2. Wie sieht der Workflow aus für 'Events', die nach dem CI/CD in die single source of truth einfliessen? ZB. abnahmen auf einer Abnahme Stage, oder Integrationsprobleme auf einer test Stage  
-
-##### Aufgabe
-
-Es sollen existierende, typische Pipelines hergenommen werden und auf die oben skizzierten Fragestellungen hin untersucht und angepasst werden.
-In lokalen Demo-Systemen (mit oder ohne CNOE aufgesetzt) sollen die Pipeline entwürfe dummyhaft dargestellt werden und luffähig sein.
-Für den POC sollen Workflow-Systeme wie Dagger, Argo Workflow, Flux, Forgejo Actions zum Einsatz kommen. 
-
-##### Description
-
-### Stream 'POCs'
-
-#### Activity 'CNOE investigation'
-
-tbd
-
-#### Activity 'Asset "SIA" Deployment'
-
-tbd
-
-### Stream 'Deployment'
-
-#### Activity 'Forgejo'
-
-tbd

content/en/docs/project/streams/deployment/_index.md

@@ -0,0 +1,4 @@
+---
+title: Deployment
+weight: 3
+---

content/en/docs/project/streams/deployment/forgejo/_index.md

@@ -0,0 +1,14 @@
+---
+title: Activity 'Forgejo'
+linkTitle: Forgejo
+weight: 1
+---
+
+### Rationale
+
+
+### Task
+
+
+
+

content/en/docs/project/streams/fundamentals/_index.md

@@ -0,0 +1,4 @@
+---
+title: Fundamentals
+weight: 1
+---

content/en/docs/project/streams/fundamentals/cicd-definition/_index.md

@@ -0,0 +1,24 @@
+---
+title: Activity 'CI/CD Definition'
+linkTite: CI/CD Definition
+weight: 2
+---
+
+
+## Rationale
+
+In Gitops basierten Plattformen (Anm.: wie es zB. CNOE und Humanitec mit ArgoCD sind) trifft das klassische Verständnis von Pipelining mit finalem Pushing des fertigen Builds auf die Target-Plattform nicht mehr zu.
+
+D.h. in diesem fall is Argo CD = Continuous Delivery = Pulling des desired state auf die Target plattform. Eine pipeline hat hier keien Rechte mehr, single source of truth ist das 'Control-Git'. 
+
+D.h. es stellen sich zwei Fragen:
+1. Wie sieht der adaptierte Workflow aus, der die 'Single Source of Truth' im 'Control-Git' definiert? Was ist das gewünschte korrekte Wording? Was bedeuen CI und CD in diesem (neuen) Kontext ? Auf welchen Environmants laufen Steps (zB Funktionstest), die eben nicht mehr auf einer gitops-kontrollierten Stage laufen?
+2. Wie sieht der Workflow aus für 'Events', die nach dem CI/CD in die single source of truth einfliessen? ZB. abnahmen auf einer Abnahme Stage, oder Integrationsprobleme auf einer test Stage  
+
+## Aufgabe
+
+Es sollen existierende, typische Pipelines hergenommen werden und auf die oben skizzierten Fragestellungen hin untersucht und angepasst werden.
+In lokalen Demo-Systemen (mit oder ohne CNOE aufgesetzt) sollen die Pipeline entwürfe dummyhaft dargestellt werden und luffähig sein.
+Für den POC sollen Workflow-Systeme wie Dagger, Argo Workflow, Flux, Forgejo Actions zum Einsatz kommen. 
+
+

content/en/docs/project/streams/fundamentals/platform-definition/_index.md

@@ -0,0 +1,14 @@
+---
+title: Activity 'Platform Definition'
+linkTitle: Platform Definition
+weight: 1
+---
+
+### Rationale
+
+
+### Task
+
+
+
+

content/en/docs/project/streams/pocs/_index.md

@@ -0,0 +1,5 @@
+---
+title: POCs
+weight: 2
+---
+

content/en/docs/project/streams/pocs/cnoe/_index.md

@@ -0,0 +1,14 @@
+---
+title: Activity 'CNOE'
+linkTitle: CNOE
+weight: 1
+---
+
+### Rationale
+
+
+### Task
+
+
+
+

content/en/docs/project/streams/pocs/sia-asset/_index.md

@@ -0,0 +1,14 @@
+---
+title: Activity 'SIA Asset'
+linkTitle: SIA Asset
+weight: 2
+---
+
+### Rationale
+
+
+### Task
+
+
+
+

hugo.toml

@@ -156,3 +156,9 @@ enable = false
   [[module.imports]]
     path = "github.com/google/docsy"
     disable = false
+
+[params.mermaid]
+version = "10.9.0"
+
+[params.markmap]
+enable = true