# PLT-47008 - Workflow ideas for rsi-website

In [PLT-47008](https://cloudimperiumgames.atlassian.net/browse/PLT-47008), we are looking for the best first iteration to deploy rsi-website QA environments, dynamically, in ArgoCD. We would like to avoid any major changes on developer workflow, we want the ArgoCD integration as smooth and natural as possible.

## Solution 1: deploy ArgoCD Application from rsi-deployment

graph LR
	A{{repo rsi-deployment}}-->|argo app create|B[ArgoCD]-->|build|C((Application))-->|deploy|D[Kubernetes]

⚠️ How to push variables from rsi-deployment to ArgoCD?

The rsi-deployment GitLab pipeline will deploy the Application in ArgoCD on it's own. It requires "TemplateTransformer" Kustomize plugin. We add a step to the pipeline like `argocd app create ${tag_name}...` ([doc](https://argo-cd.readthedocs.io/en/stable/user-guide/commands/argocd_app_create/)). Basically the pipeline control the app creation workflow, which could be nice if we want to benefit from the "environment" GitLab feature, as it will add more management over the ArgoCD application from the pipeline.

:::success
**Pros**
- Seems to be a quick way to support ArgoCD
- Dynamic ArgoCD deployment managed from GitLab pipeline
- Support GitLab Environment easily
:::

:::danger
**Cons**
- Limited use of ArgoCD power as we manage it using GitLab pipeline - No use of ApplicationSet
- Use of individual ArgoCD Application means also individual management for each - or GitLab Environment management
- Requires Kustomize plugin "TemplateTransformer" installed in ArgoCD
:::

## Solution 2: Generate a manifest that ArgoCD will deploy

graph LR
	A{{repo rsi-deployment}}-->|build manifest|B((artifact where?))
	B-->|argo app create|C[ArgoCD]
    C-->|build|D((Application))-->|deploy|E[Kubernetes]

Idea is to build the manifest from kustomize with all required variables inside and then, using ArgoCD cli, create application in ArgoCD. In thise case, artifact may be created in the rsi-website repository which cause some security concern regarding credentials and token being exposed to too much people. As a workaround, we could use Vault.

:::success
**Pros**
- May support Vault
- Dynamic ArgoCD deployment managed from GitLab pipeline
- Support GitLab Environment easily
:::

:::danger
**Cons**
- Limited use of ArgoCD power as we manage it using GitLab pipeline - No use of ApplicationSet
- Use of individual ArgoCD Application means also individual management for each - or GitLab Environment management
- May require an extra step to support Vault in Kubernetes cluster and in pipelines
:::

## Solution 3: rsi-deployment to create a Merge Request with final files

graph LR
    A{{repo rsi-deployment}}-->|prepare Kustomization file|B((merge request with label))
    C((ApplicationSet))-->|check MR labels|B
    C-->|create app|D[ArgoCD]
    D-->|deploy|E[Kubernetes]

On this one, we may simply compile vars using envsubst to generate kustomize file, like we would do in Solution 2, but here we would generate a new merge request under rsi-deployment with a special label. ApplicationSet from ArgoCD monitors Merge Request with defined label and will deploy it as expected. When the Merge Request is destroyed, the deployment is destroyed as well.

:::success
**Pros**
- ArgoCD way using ApplicationSet with a Pull Request generator
- GitLab environment may be built from this Merge Request, so the stop function should also close the MR and destroy the deployment
:::

:::danger
**Cons**
- May "flood" Merge Request side of GitLab, so will required to filter out the named label
:::