website-and-documentation/content/en/docs/project/streams/_index.md

---
title: Streams
weight: 1
---

This page is WiP. Stefan and Stephan try to solve the mission 'wir wollen losmachen'.

Idea: 

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 knoeledge and outcomes in these activities.
1. Next the whole team decides which are the next valuable steps

## Overall Structure: Streams

We discovered three **streams** in the first project steps (see also [blog](../../../blog/news/240823-archsession/_index.md)):

1. Research, Fundamentals, Architecture
1. POCs (Applications, Platform-variants, ...)
1. Deployment, production-lifecycle

## Proposal of Activities aka User Stories in the streams



### Stream 'Research'

#### Activity 'Platform-Defintion'

#### Activity 'CI/CD Defintion'

##### 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