How to release a app in staging at first

[fearlesschenc]

Let's say when we release a new podinfo chart, as HelmRelease will scan that chart in 5m, then new podinfo app will deployed on both production and staging environment.

Is there a way we can deploy in staging environment first?

[aleclerc-sonrai]

We've had a lot of growing pains using a layout like this for some time now and I haven't landed on a good solution. Your example is a good one, but there are lots of others in terms of "how do i put something in stage first, and eventually promote it up?". Most of them time it involved a lot of yaml manipulation. (We're still on flux v1, but i think v2 just adds one level of indirection in this case)

In your case, I'm assuming you wouldn't have 'prod' pointing to the master branch, but maybe a tag. Then you could increase the chart tag in the stage yaml patch file, and ones it's good to go, you would make one commit to remove it from the stage file, and set that chart version on the 'base'

Version increases are easier because they're managed in the environment values file already, but anything that is a bit more complex becomes pretty involved. For instance, adding a key to the values in a helm-release. We we only want to do it in stage initially, but then to promote it up, eventually we want it to get to prod. Similarly, I would add the key in the stage values: https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/apps/staging/podinfo-values.yaml

Then once i was happy with it, I would 'promote' the change into production, probably in here https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/apps/base/podinfo/release.yaml and remove it from stage. Alternatively I COULD also put it in prod values (https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/apps/production/podinfo-values.yaml) but then I'd have it on two places going forward.

[fearlesschenc]

@aleclerc-sonrai I just figure out how to use this pattern in multi-environment. This repo shows the detail, but let me explain why i did this.

We are talking about git-ops, not helmchart-ops or s3bucket-ops. So, the only way we deploy or update something, should be commit codes. That's the reason i put charts into repo directly(whether infra or apps) to prevent a release triggered by some incompatible infra charts.

And i use a staging branch to bootstrap staging environment, So if i have updates, i should update staging branch first, i won't influence master/main branch, so it won't influence production environment. And if everything works fine, i would merge staging into main, and push it.

I made /apps a registration place, when we add an app, we should add it here to make it works.

The others are barely the same, what i do is unify sources, and separate deployment by branch.