From 580cfa960e2d961b758dbbe056d7e8bb11997589 Mon Sep 17 00:00:00 2001 From: Stephan Lo Date: Sat, 24 Aug 2024 15:05:04 +0000 Subject: [PATCH] doc(project): initial description of activities CNOE, Fundamentals, SIA Asset and CI/CD ready --- .../fundamentals/cicd-definition/_index.md | 8 +++---- .../platform-definition/_index.md | 15 ++++++++----- .../docs/project/streams/pocs/cnoe/_index.md | 21 ++++++++++++++++--- .../project/streams/pocs/sia-asset/_index.md | 14 ++++++++++--- 4 files changed, 43 insertions(+), 15 deletions(-) diff --git a/content/en/docs/project/streams/fundamentals/cicd-definition/_index.md b/content/en/docs/project/streams/fundamentals/cicd-definition/_index.md index c20d6f9..2280841 100644 --- a/content/en/docs/project/streams/fundamentals/cicd-definition/_index.md +++ b/content/en/docs/project/streams/fundamentals/cicd-definition/_index.md @@ -18,10 +18,10 @@ 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 +## Task -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. +* 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. diff --git a/content/en/docs/project/streams/fundamentals/platform-definition/_index.md b/content/en/docs/project/streams/fundamentals/platform-definition/_index.md index 81f808f..c4d21c9 100644 --- a/content/en/docs/project/streams/fundamentals/platform-definition/_index.md +++ b/content/en/docs/project/streams/fundamentals/platform-definition/_index.md @@ -6,7 +6,7 @@ weight: 1 ## Summary -Das theoretische Fundament unserer Plattform-Architektur ist zu begründen und weitere wesentliche Erfahrungen anderer Player durch Recherche erheben, so dass unser Weg abgesichert ist. +Das theoretische Fundament unserer Plattform-Architektur soll begründet und weitere wesentliche Erfahrungen anderer Player durch Recherche erhoben werden, so dass unser aktuelles Zielbild abgesichert ist. ## Rationale @@ -15,10 +15,15 @@ Es gibt viele weitere Grundlagen und Entwicklungen zu Platform Engineering. ## Task -Zusammentragen, wer was federführend macht in der Plattform Domäne. -Ableiten, wie sich daraus unser Zielbild und Strategie ergeben. -Argumentation für unseren Weg zusammentragen. -Best Practices und wichtige Tipps und Erfahrungen zusammentragen. +* Zusammentragen, wer was federführend macht in der Plattform Domäne, vgl. auch Linkliste im [Blog](../../../../../blog/240823-archsession.md) +* Welche trendsettenden Plattformen gibt es? +* Beschreiben der Referenzarchitektur in unserem Sinn +* Begriffsbildung, Glossar erstellen (zB Stacks oder Ressource-Bundles) +* Architekturen erstellen mit Control Planes, Seedern, Targets, etc. die mal zusammenliegen, mal nicht +* Beschreibung der Wirkungsweise der Platform-Orchestration (Score, Kubevela, DSL, ... und Controlern hierzu) in verscheidenen Platform-Implemnetierungen +* Ableiten, wie sich daraus unser Zielbild und Strategie ergeben. +* Argumentation für unseren Weg zusammentragen. +* Best Practices und wichtige Tipps und Erfahrungen zusammentragen. diff --git a/content/en/docs/project/streams/pocs/cnoe/_index.md b/content/en/docs/project/streams/pocs/cnoe/_index.md index 408c19e..273347d 100644 --- a/content/en/docs/project/streams/pocs/cnoe/_index.md +++ b/content/en/docs/project/streams/pocs/cnoe/_index.md @@ -1,13 +1,28 @@ --- -title: Activity 'CNOE' +title: Activity 'CNOE Investigation' linkTitle: CNOE weight: 1 --- -### Rationale +## Summary -### Task +Als designiertes Basis-Tool des Developer Frameworks sollen die Verwendung und die Möglichkeiten von CNOE zur Erweiterung analysiert werden. + +## Rationale + +CNOE ist das designierte Werkzeug zur Beschreibung und Ausspielung des Developer Frameworks. +Dieses Werkzeug gilt es zu erlernen, zu beschreiben und weiterzuentwickeln. +Insbesondere der Metacharkter des 'Software zur Bereitstellung von Bereitstellungssoftware für Software', d.h. der unterschiedlichen Ebenen für unterschiedliche Use Cases und Akteure soll klar verständlich und dokumentiert werden. Siehe hierzu auch das Webinar von Huamnitec und die Diskussion zu unterschiedlichen Bereitstellungsmethoden eines RedisCaches. + +## Task + +* CNOE deklarativ in lokalem und ggf. vorhandenem Cloud-Umfeld startbar machen +* Architektur von COE beschreiben, wesentliche Wording finden (zB Orchestrator, Stacks, Kompoennten-Deklaration, ...) +* Tests / validations durchführen +* eigene 'Stacks erstellen' (auch in Zusammenarbeit mit Applikations-POCs, zB. SIA und Telemetrie) +* Wording und Architektur von Activity ['Platform-Definition'](../../fundamentals/platform-definition/) beachten und challengen +* Alles, was startbar und lauffähig ist, soll möglichst vollautomatisch verscriptet und git dokumentiert in einem Repo liegen diff --git a/content/en/docs/project/streams/pocs/sia-asset/_index.md b/content/en/docs/project/streams/pocs/sia-asset/_index.md index fa4c8c5..72b26a7 100644 --- a/content/en/docs/project/streams/pocs/sia-asset/_index.md +++ b/content/en/docs/project/streams/pocs/sia-asset/_index.md @@ -1,14 +1,22 @@ --- -title: Activity 'SIA Asset' +title: Activity 'SIA Asset Golden Path Development' linkTitle: SIA Asset weight: 2 --- -### Rationale +## Summary +Implementierung eines Golden Paths in einem CNOE/Backstage Stack für das existierende 'Composable SIA (Semasuite Integrator Asset)'. -### Task +## Rationale +Das SIA Asset ist eine Entwicklung des PC DC - es ist eine Composable Application die einen OnlineShop um die Möglichkeit der FAX-Bestellung erweitert. +Die Entwicklung begann im Januar 2024 mit einem Team von drei Menschen, davon zwei Nearshore, und hatte die typischen ersten Stufen - erst Applikationscode ohne Integration, dann lokale gemockte Integration, dann lokale echte Integration, dann Integration auf einer Integrationsumgebung, dann Produktion. Jedesmal bei Erklimmung der nächsten Stufe mit Erstellung von individuellem Build und Deploymentcode und Abwägungen, wie aufwändig nachhaltig und wie benutzbar das jeweilige Konstrukt sein sollte. +Ein CI/CD gibt es nicht, zu großer Aufwand für so ein kleines Projekt. +Die Erwartung ist, dass so ein Projekt als 'Golden Path' abbildbar ist und die Entwicklung enorm bescheunigt. +## Task +* SIA 'auf die Platform heben' (was immer das bedeutet) +* Den Build-Code von SIA (die Applikation und einen Shop) in einen CI/CD Workflow transformieren