#gitops (2020-03)
Discuss continuous delivery of infrastructure
Archive: https://archive.sweetops.com/gitops/
2020-03-10
Hello all
Have a scenario I’d love some input with. We run around 18 microservices, a mixture of frontends and backends. As with many companies we have ended up with the monolithic microservice architecture and thus we often need to release things at the same time to prevent downtime on production. We have now successfully implemented FluxCD on our staging namespace. We have two more namespaces/environments, sandbox and production. We have not yet implemented flux in these namespaces. The issue we have to now is how best to implement flux and promote services from stage>sandbox>prod. It has been suggested we could use develop and master branches. If anyone could expand on that or add anything I’d be super grateful. Hope you all have a great day
Sounds like gitflow https://datasift.github.io/gitflow/IntroducingGitFlow.html
and gitflow is probably a thing you don’t want/need
In what sense?
Git Flow has fallen out of favor for simpler strategies. There was recently a HN post on this: https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/
Thats the one
Thx @Erik Osterman (Cloud Posse)
Question is do you do actual environment promotion or do you simply deploy at whim to any number of environments?
If you are actually promoting then having a single release git repo with various branches aligned with each step in the promotion process makes sense as you can easily automate PRs and such.
Otherwise I suspect it would be just as easy to simply have one deployment repo per environment and PR approve your release versions in the manifests therein.
that way your repo is more like a docker-compose file with multiple microservices comprising the whole of an environment
All super helpful information. Appreciate it greatly!
We would probably stick to a single repo because we kustomize to manage the templating
My issue originally is that we tag the images differently between stage (commit #) and sandbox/prod (v*). My thoughts now are
- One branch per environment (stage, sandbox, prod)
- One flux patch for staging on automated releases
- One flux patch for sandbox and prod with automated releases for sandbox deployments and not for prod.
- Sandbox always stays up to date with latest semantic tag and updates the flux-patch file.
- On merge to from sandbox branch to prod branch prod applies ALL infra changes and ALL application updates at the same time from the flux patch file
2020-03-11
2020-03-27
Adding @discourse_forum bot
@discourse_forum has joined the channel
2020-03-30
Trying to find docs on this….
if I want to apply actions, templates, settings or anything across all my org in github, isn’t there a .github special repository you can create and all the child repositories inherit this, for instance with CODE_OWNERS for example? I thought there was a special repo for github that allowed this, like the .github name or something (not the folder in each github, I’m aware of that one)
Ya, no way to do that across repositoryies
the .github directory is just a place to store github-specific configurations inside of a single repository
Thanks for confirming. Therefore codeowner would be done on all repos not one central. Makes sense in the git world for sure
I just found more documentation supporting a central .github repo for an org… Look at this section
