This message was deleted.

Using branches is not a good idea imo. Promoting between environments is never a simple merge. There are often persistent differences between envs. So you would have to patch your branches before merge, etc. Plus if you keep code and config in the same repo. How much tailoring is required if you want to roll out a config change, but you don't want to roll out a code change? I think this is unmanagable. A classic in the topic: https://codefresh.io/blog/stop-using-branches-deploying-different-gitops-environments/ So use folders for the env configs. And promote your version numbers, etc across them. Now this is manual work that can be automated. I don't think there is a tool out there that can do: • promoting configs accross envs • manual / on demand deploys • AND taking into account a strict worflow: E2E test must pass before you can release on prod etc.

@Laszlo Fogas Thanks for the insight and the link, my org uses both folders and branches. The branch protection for us just adds a layer to make sure no one can merge directly to main/prod and go through the env progression we’ve setup.

@Randy Schneiderman does your team also use Bazel for builds with the monorepo?

No we just have Chekov but I would love to explore other tools and automated testing to integrate with GitHub to ensure changes are valid, secure, and documented.

Ahh yes checkov is great! I’ve used the commercial product as well (BridgeCrew) which is also very good

Hi @Andrew Dennis I've come across Bazel before, and it appears to be in use within our organization, but I haven't had the opportunity to work with it directly. I'm eager to delve into it now. Do you have any tutorial links or resources you could recommend for getting started with Bazel?

👋 sorry for this late reply, but this piqued my interest when I saw it in the email roundup for this group. We had the same problem in my last place and we also opted for the env per folder approach. In the end, what we really wanted was automated progressive delivery from one environment to the next. So that changes flowed automatically all the way to production. We ultimately ended up building this promotion automation to copy e.g. image versions defined in one env folder to the next, based on a progression through our environment phases (staging, pre-prod, prod and so on). This promotion automation actually opened up PRs to propose the change, but automatically put those PRs into a merge queue, so no one had to be around to merge them. My experience working on that stuff has fed into a little experiment project we’re doing now called cup. Cup doesn’t do the promotion bit (yet at-least), but it helps to create an API over Git that when you request the repo to be in a new desired state, they automatically become PRs. A step towards making that kind of automation easier to develop.

Also late reply: I'm the Bazel person in this slack. Starting with https://bazel.build is good, and there's a general purpose tutorial on my docsite https://docs.aspect.build/tutorial/ If you want to learn Bazel with a particular language, there are specific tutorials for some of those as well.