Merge remote-tracking branch 'refs/remotes/origin/development' into development

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

@@ -0,0 +1,39 @@
+---
+title: Architecture session
+weight: 20
+---
+
+
+## Platform Generics
+
+* https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms
+
+* https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
+
+* https://humanitec.com/blog/wtf-internal-developer-platform-vs-internal-developer-portal-vs-paas
+
+## reference architecture + Portfolio
+
+* https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures
+
+* https://humanitec.com/reference-architectures
+
+* https://www.youtube.com/watch?v=AimSwK8Mw-U
+
+
+## Platform Portfolio
+
+### Viktor Farcic
+
+* https://technologyconversations.com/
+
+* https://technologyconversations.com/2024/01/08/the-best-devops-tools-platforms-and-services-in-2024/
+
+
+### Internal devloper platform
+
+* https://internaldeveloperplatform.org/core-components/
+
+### Workflow / CI/CD
+
+* https://cnoe.io/blog/optimizing-data-quality-in-dev-portals

content/en/docs/project/_index.md

@@ -0,0 +1,6 @@
+---
+title: Project
+weight: 5
+---
+
+Here we document organisation, vision, plan, outcomes of the IPCEI-CIS Developer Platform project.

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

@@ -0,0 +1,64 @@
+---
+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