Architecture Decision - how to handle multiple demo environment instances #219

[wrichter]

@DanielFroehlich your input is required here - is it necessary for the VERSION file to reside in manuela-dev and could it be also moved to Manuela-gitops? thinking is that we now have multiple instances of manuela (Edge ILT team, Keith, ...), and all would share the same manuela-dev (at least in the beginning) and step on each others toes...

[DanielFroehlich]

it is not required, but for me, it is a natural fit. A version belongs to the component. Of course we could move it, but i would consider it very counter intuitive and difficult to explain ("Yea, the version file location is a bit strange, that is due to multi demo capabilties" --> we will probably loose part of the audience).

How about moving difference instances of the demo to different branches of the repo? Regarding QUAY, we could stay with the manuela organisation and use different labels (e.g. demo instance as preview, e.g. "manuela-3.2.1" and "keith-3.2.1".

[wrichter]

Thinking about it a bit more, a new demo environment would need both their own manuela-dev and manuela-gitops repos (or at least their custom branches), since running the coding change demo requires changes to the code in manuela-dev as well (and you don#t want to step on each others toes). This reduces the value of putting the VERSION file in manuela-gitops.

Using a custom branch requires at least write access to manuela-dev, which won't necessarily work if you have other teams setting up the demo.

[DanielFroehlich]

I think this a broader issue which sparks off the VERSION. We need an archiectural decision on how we map/implement multipl demo-instances.

Option#1: BRANCHES inside the existing sa-mw-dach repos, for each manuela demo env there would be a branch. TODO: define a convention for this. Pro:

• ? Cons:
• write access to all demoers would be needed

Option #2: FORKS The "owner" of the new installation forks all repos. There would be somewhere one central configuration (GIT_BASE_URL) defining from which fork to pull from.

Option #3: DEDICATED GIT We could deploy a dedicated GIT(LAB?) to manuela-ci, place the code there and stick to the existing Pro:

• ? Cons:
• ?

[wrichter]

Option 1: Pro: Easiest to set up since it's literally just cloning the central repos. Con: Gut feel: i don't like it due to the cluttering of branches for execution and development and the need to give everyone write access. Impact: Needs to make branch names configurable, feels like little benefit over making Repo URLs configurable.

Option 2a) Own GitOps repo, forked dev repo: same as 2, only with a "fresh" gitops repo Pros:

• this is what's already documented in SETUP.MD Cons:
• ?

Option 3) If we have dedicated git(lab), all repo URLs will change with each deployment. We could try to use internal .svc.cluster.local URLs, but this will not work beyond a single cluster (unless we introduce tools such as skupper). Therefore it feels like Option 2 with extra steps.

[wrichter]

Suggestion: https://github.com/sa-mw-dach/manuela/blob/master/docs/architecture/decisions/0007-how-to-implement-multiple-demo-instances.md

[DanielFroehlich]

LGTM -> Close!

[wrichter]

I'll change the ADR to accepted then