How to Effectively Use ArgoCD and Kargo for GitOps Deployments?

0
4
Asked By CuriousCoder94 On

I've set up ArgoCD and it's been running well overall, but I'm facing a challenge when it comes to testing deployments. Currently, I need to push changes to the main branch to get Argo to apply updates, which doesn't feel ideal. I'm also trying to avoid using labels since that feels counterintuitive if the data isn't tracked in Git.

Recently, I came across Kargo and found its flow to be quite interesting. It watches for changes, creates a change set, and promotes that set through various stages. However, I noticed that when I have both a version change and a config tweak for a new helm chart, Kargo doesn't seem to handle combined edits well.

For example, if I want to promote a change to version 2.x along with some updates to values.yaml for staging, and then apply this same configuration to production, it feels like Kargo only supports artifact promotion without considering git/config changes.

Am I missing something here? What strategies do others use to promote changes through different environments efficiently? Right now, I'm just committing directly to main since everything is still in staging, but I feel that this isn't the best practice.

3 Answers

Answered By DevOpsNerd123 On

Based on your setup, it seems like you're encountering a design flaw. There's no need to push changes to main just to test in staging. What you can do instead is hold your changes in a feature branch until you're ready to promote them.

Answered By DeployDude88 On

It sounds like you're on the right track. If you have separate deployments for staging and production, you can commit both the version bump and config changes directly to the staging branch of the same repo and let Argo handle the rollout. Once you're confident everything works in staging, you can then apply that same change to production. Kargo mainly assists with promoting artifacts, but you'll still want some environment-specific configurations in Git. Promotion is usually done by cherry-picking changes or advancing the same Git diff across branches instead of creating a separate PR for each environment.

Answered By TechSavvySammy On

I feel you there! Using ApplicationSets and Kustomize together has been a game-changer for me. Kustomize lets you manage different configurations across environments easily. When I want to test new changes, I usually create a temporary branch to sync from instead of pushing directly to main. This way, I can isolate tests without messy merges.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.