5 ms·

Flux with GitOps approach, using Helm charts. All of our of microservices have deployment charts, with frozen image versioning. That way, we can can rollout a

by klohto 6y ago

Flux with GitOps approach, using Helm charts. All of our of microservices have deployment charts, with frozen image versioning. That way, we can can rollout a whole release knowing they are all compatible with each other and can easily fall back just by using git rollback. CI/CD updates image versions in affected YAMLs on every backend release and Flux keeps staging in sync. When we are happy, we sync to production branch, Flux syncs and it's done. If we spot an issue that we didn't see in staging, we either release a hotfix or rollback.

dclausen 6y ago
Could you explain more about your "frozen image versioning?"
- klohto 6y ago
  Was wondering if I just invented the term, or it’s something known :) Basically a specific semver, no major.minor or just major. Whole version including patch.
computershit 6y ago
Have you looked into Jenkins-X at all? I'm at a point where I'm starting to adopt GitOps and I'm torn between Flux and (what I consider) a far more opinionated but pretty elegant solution in JX.
- klohto 6y ago
  I did, it’s overly complicated for what I need (single team, apply YAMLs in git repo, specific branch, tagging). I see the industry using mostly Flux and ArgoCD and I really don’t want anything Jenkins related in infra again.
  - computershit 5y ago
    Yeah I am leaning that direction too. Thanks for the reminder about Argo.
theptip 6y ago
Do you have a separate git repo for the deploy config/manifests? Or just force-push your `master` branch to the `staging` and `production` branches to do a deploy (i.e. not keeping full history in the env branches)? I've seen both advocated for, interested in what the consensus is.
- klohto 6y ago
  We have gitops repo which contains state of both clusters. Staging and production. The only difference is that production flux watches only production folder and production branch, while staging flux watches staging folder and master branch. Production branch is kept in sync with master when releasing, ff-only. Backend is a monorepo. I can easily check the commit history in gitops repo to see what was the state of backend when the release was made. Nothing should be lost, we keep history of everything this way.

by klohto 6y ago

dclausen 6y ago

Could you explain more about your "frozen image versioning?"

klohto 6y ago
Was wondering if I just invented the term, or it’s something known :) Basically a specific semver, no major.minor or just major. Whole version including patch.

computershit 6y ago

Have you looked into Jenkins-X at all? I'm at a point where I'm starting to adopt GitOps and I'm torn between Flux and (what I consider) a far more opinionated but pretty elegant solution in JX.

klohto 6y ago
I did, it’s overly complicated for what I need (single team, apply YAMLs in git repo, specific branch, tagging). I see the industry using mostly Flux and ArgoCD and I really don’t want anything Jenkins related in infra again.
- computershit 5y ago
  Yeah I am leaning that direction too. Thanks for the reminder about Argo.

theptip 6y ago

Do you have a separate git repo for the deploy config/manifests? Or just force-push your `master` branch to the `staging` and `production` branches to do a deploy (i.e. not keeping full history in the env branches)? I've seen both advocated for, interested in what the consensus is.

klohto 6y ago
We have gitops repo which contains state of both clusters. Staging and production. The only difference is that production flux watches only production folder and production branch, while staging flux watches staging folder and master branch. Production branch is kept in sync with master when releasing, ff-only. Backend is a monorepo. I can easily check the commit history in gitops repo to see what was the state of backend when the release was made. Nothing should be lost, we keep history of everything this way.