Hey Anais, great explanation and a really important topic to touch upon. Just a tiny feedback, the music background was a little bit too much for me. But again I very much liked the content and everything.
Hey Anais, great video. I learned something today ;) Just a question: you have your kustomize/manifests in a specific branch, called kustomize. Is that some kind of best practice? If so, do you know why? Thanks. I normally use a folder in the main branch called pipeline for CICD stuff and another called k8s for the manifests or helm charts.
I wonder how would you incorporate this approach into CI build pipeline? I think right now you assume that image building and manifest creation is done locally?
So the plan is to have the following steps 1. Build container image and push to registry 2. Update the image tag referenced in Kustomize 3. Run Kustomize build 4. ArgoCD will automatically sync the changes from Git with the in-cluster resources I will show that in my next video
@@AnaisUrlichs thanks, that would be interesting to watch. I would also be keen to know your opinion on using a separate config repo for argocd. Right now any change to manifest files (even adding a comment) would result in new image build and deployment which might not be desirable in production like setups.
@@havefuntrading6263 The way my company has it set up, is that CI is responsible for testing and building images. In the same project repo, we have a "deployments" folder and manifests for each environment (sandbox, staging, and production). To kick off a deployment to sandbox, for example, someone commits an update to the image tag to "deployments/sandbox/values.yaml". ArgoCD in the sandbox environment is configured to look at that `values.yaml` file, sees the change, and deploys it. Promoting to a higher environment (e.g. sandbox to staging) is a matter of updating "deployments/staging/values.yaml".
@@mtik000 thanks for the explanation. When you update a deployment file to e.g. trigger deployment to staging will this also trigger the CI build and create new image version?
@@havefuntrading6263 Not the way we do it, no. CI builds the images during merges of source code to the main branch. When we want to "promote" a release to sandbox, e.g., a dev selects an image tag and manually commits the change to "deploy/sandbox/values.yaml" on the "main" branch, then merges that to the "sandbox" branch. ArgoCD (deployed on our sandbox cluster) sees _that_ change, and does the deploy. Once that tag is tested, the same tag is committed to "deploy/staging/values.yaml" on the "main" branch and merged to the "staging" branch. ArgoCD (deployed on our staging cluster) sees _that_ change, and does the deploy. To be honest, it's a little confusing dealing with the branches and the directories. We just have to remember to commit to the appropriate file in the main branch and then merge it to the branch that ArgoCD is watching.
Heya, I used Helm Charts in my previous video on ArgoCD :) I could make a video on why you would want to use Helm and in which cases kustomize etc. would you be interested in that?
