30 lines
1.7 KiB
Markdown
30 lines
1.7 KiB
Markdown
|
---
|
||
|
|
title: Activity 'CI/CD Definition'
|
||
|
|
linkTite: CI/CD Definition
|
||
|
|
weight: 2
|
||
|
|
---
|
||
|
|
|
||
|
|
## 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/
|