As a developer, I want to manage the versioning of my deployment/application.

[ThomasCardin]

Executive summary

We want to manage the different versions of our applications and test them progressively (for example, a frontend developer wants to test the version of the backend that is in the testing phase on a PR). We need to have a deployment for each version.

Context

If a user creates a PR, an automatic deployment should be carried out with the correct version (via the Dockerfile, based on the specific file of each directory. For example, for the frontend, it should refer to the package.json). Afterward, the URL of this deployment should be displayed in the pull request (for example, https://v1-0-0.nachet.ninebasetwo.xyz/ for the frontend and https://v1-0-0.nachet.ninebasetwo.xyz/api for the backend). Subsequently, a developer could test https://"x".nachet.ninebasetwo.xyz at any time.

How to do it

• Automatic deployment of an image version (application) with ArgoCD to Kubernetes.
• Tag the Docker image with the version specified in the specific file (for example, package.json for the frontend).
• For routing, modify the LB Ingress NGINX to point to a specific version. For example, if a frontend application is on version v1.0.0, its URL would be https://v1-0-0.nachet.ninebasetwo.xyz/. When someone clicks on this URL, the backend will automatically communicate with https://v1-0-0.nachet.ninebasetwo.xyz/api (v1-0-0 being the corresponding version for the backend).

Summary

• Each PR for each application has a URL. The frontend URL always points to the corresponding version of the backend (https://v1-0-0.nachet.ninebasetwo.xyz/ -> https://v1-0-0.nachet.ninebasetwo.xyz/api). The LB needs to be configured for this.
• A new tag is added to the Dockerfile (the version tag).

Regarding the Dockerfiles of the projects, ARGs need to be retained at build time (for example, docker build...).

Steps:

• Modify this github action to tag the image with the corresponding tag of the application #127
• Deploy ArgoCD and migrate deployed application to argocd #61
• Setup Kustomize #60
• Setup the Github login for ArgoCD #62
• Vault plugin for ArgoCD #129
• Configure an Argo Workflows to generate and apply k8s manifest from the PR #128
• (Maybe) Configure any application deployment from kubernetes/aks/apps to have the kind Rollout
• Display the new URL inside the PR #232
• Configure the LB Ingress NGINX to point the frontend to the specific backend version (e.g https://v1-0-0.finesse.ninebasetwo.xyz -> https://v1-0-0.finesse.ninebasetwo.xyz/api)
• Write and create architecture diagrams for documentation #233

EDIT:

After some research, @SonOfLope found this workflow. This could save us a lot of time. If the solution works, some of the earlier steps won't need to be done.

• Implement this workflow in the appropriate directories. #231

[rngadam]

review ADR: https://github.com/ai-cfia/dev-rel-docs/blob/main/adr/006-database-change-management.md

also : https://www.ietf.org/rfc/rfc1034.txt#:~:text=They%20must%20start%20with%20a,be%2063%20characters%20or%20less.&text=information%2C%20which%20may%20be%20empty.)

They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. information, which may be empty.

I suggest substituting . for - so v2.3.30 becomes v2-3-30

[SonOfLope]

https://github.com/marketplace/actions/preview-pull-requests-in-kubernetes