Fundamentals

• 1: Activity 'Platform Definition'
• 2: Activity 'CI/CD Definition'

1 - Activity 'Platform Definition'

Summary

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

Wir starten gerade auf der Bais des Referenzmodells zu Platform-Engineering von Gartner und Huamitec. Es gibt viele weitere Grundlagen und Entwicklungen zu Platform Engineering.

Task

• Zusammentragen, wer was federführend macht in der Plattform Domäne, vgl. auch Linkliste im Blog
• 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.

2 - Activity 'CI/CD Definition'

Summary

Der Produktionsprozess für Applikationen soll im Kontext von Gitops und Plattformen entworfen und mit einigen Workflowsystemen im Leerlauf implementiert werden.

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

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.

Further ideas for POSs

• see sample flows in https://docs.kubefirst.io/