#gitops (2020-03)

Discuss continuous delivery of infrastructure Archive: https://archive.sweetops.com/gitops/

2020-03-31

2020-03-30

sheldonh avatar
sheldonh

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)

Erik Osterman avatar
Erik Osterman

Ya, no way to do that across repositoryies

Erik Osterman avatar
Erik Osterman

the .github directory is just a place to store github-specific configurations inside of a single repository

sheldonh avatar
sheldonh

Thanks for confirming. Therefore codeowner would be done on all repos not one central. Makes sense in the git world for sure

1

2020-03-27

Erik Osterman avatar
Erik Osterman

Adding @ bot

discourse_forum avatar
discourse_forum
10:04:20 PM

@ has joined the channel

2020-03-11

2020-03-10

Thomas Burton avatar
Thomas Burton

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

joshmyers avatar
joshmyers

and gitflow is probably a thing you don’t want/need

Thomas Burton avatar
Thomas Burton

In what sense?

Erik Osterman avatar
Erik Osterman

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/

https://news.ycombinator.com/item?id=22485489

joshmyers avatar
joshmyers

Thats the one

joshmyers avatar
joshmyers

Thx @Erik Osterman

Zachary Loeber avatar
Zachary Loeber

Question is do you do actual environment promotion or do you simply deploy at whim to any number of environments?

Zachary Loeber avatar
Zachary Loeber

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.

Zachary Loeber avatar
Zachary Loeber

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.

Zachary Loeber avatar
Zachary Loeber

that way your repo is more like a docker-compose file with multiple microservices comprising the whole of an environment

Thomas Burton avatar
Thomas Burton

All super helpful information. Appreciate it greatly!

Thomas Burton avatar
Thomas Burton

We would probably stick to a single repo because we kustomize to manage the templating

Thomas Burton avatar
Thomas Burton

My issue originally is that we tag the images differently between stage (commit #) and sandbox/prod (v*). My thoughts now are

  1. One branch per environment (stage, sandbox, prod)
  2. One flux patch for staging on automated releases
  3. One flux patch for sandbox and prod with automated releases for sandbox deployments and not for prod.
  4. Sandbox always stays up to date with latest semantic tag and updates the flux-patch file.
  5. 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
    keyboard_arrow_up