This message was deleted.

I lean towards very short lived (a day or two max) branches for all, so yes? 😅

Just to make sure that we understand one another. You think that infrastructure code repo's should use the same branching strategy as an application development repo, is that what you are saying ? And the reason I am asking is because infrastructure provisioning/development code does not really have the same phases as an application development, at least not from my perspective, but if you can please change my mind :) I am the main responsible for making IaC where I work, sometimes it is transforming existing Cloud Infrastructure to IaC and sometimes it is designing new cloud solutions and the code for it. And as I see, it is difficult to compare the way you change the functionality of a button (application side) to creating an IaC solution (infrastructure side). I guess it might be a maturity thing since we are only 3 DevOps/SRE guys and the Cloud for our company is still fairly new. So I asked to what other people in here have experienced and what have worked well for them 🙂

Yup! My experience is that infra code needs as much testing / roll out as any software code. While it may not have as mature tooling in place, it has been possible in my experience. I would suggest maybe looking at things Kief Morris has written in this space?

I’ve done a fair amount of IaC and I personally don’t think you should follow the same strategy as your application code. What I did in the past was having different folders for different environments.

alright that makes sense. As of right now, what I have done to structure the IaC I have create a folder structure like so: • IaC-repo ◦ Bicep ▪︎ infra-1 ▪︎ infra-2 ▪︎ infra-3 ◦ Terraform ▪︎ infra-1 ▪︎ infra-2 ▪︎ infra-3 And as for branching I am primarily using main branch, but that is mostly because it does not make sense right now to do PR's because of missing hands. But I do believe that when creating new or changing existing IaC there should be some way to track the changes/additions. Like: 1. Work item created that requests new infrastructure 2. Create branch based on that work item to track work 3. When work is done create PR 4. PR approved and branch merged to main And testing of course happens through the whole process both before, in between and after the PR.

That’s right…

IaC or config management? two different things although they seem to get conflated… i think the code for infra should be reusable and should follow the same branching strategy as code. The problem (i think) comes in when the “infra” or platform team doesn’t have a dev and staging environment… the dev and staging environments are more like production for them then for anyone else… if i break dev i stop work my customers are impacted… so i need an account to validate and unit test my code before pushing to prod which is all of the environments including prod that the business relies. if the same IaC isn’t used to make resources in dev as in staging and as in prod then the environments will be different and then you have snowflakes and have a horrible work / life balance … so same code to deploy everything in all environments with as much similarity to code deployments as possible… which i think includes avoiding a monolith of resources with entire accounts resources defined in one repo and instead have micro services with resources clustered into specific repos… etc so feature/chore/bug branch deploys to an account that is not “production” and then merge to main where that same code is deployed and configurations are different based on environment vars (or how ever config is stored json or param store or dynamobd etc)

you’re right! the least error prone is to have the monolith approach, but the best approach is to extract the variables, but doesn’t make sense to have a dev.json file in your main branch

if you don’t have dev.json in the main branch then you have more than one repo not a branching strategy….

You don’t need a branching strategy at all…branching strategy implies whatever is in that branch is specific for that environment

correct - we don’t need to do what is right - but i don’t want to work at the auto parts company before phoenix project i want to work there three years later

It’s whatever makes sense for you…you could take another approach like this:

i do agree it is what ever makes sense to the development teams and those doing the work - but i don’t want to see them called at 2 am to fix something because a change to main in a feature branch cannot be merged back to main and proven to work and be pushed where it is needed without some siloed knowledge… i want team A to be able to go work on something else and team B to pick up the work so while it is what ever makes sense to “you” it is also what makes sense to the entire engineering org - scale breaks at some point -

Got you! Makes sense! And often times the whole org needs to be on the same page…

“relative reality” we are both likely right 🙂 culture and context are likely more important than any of my musings on this in this thread 🙂

IAC is a code repo, so just treat everything as code. It is a principal and should apply to requirement, dev, testing, rollout, and everything related.

Since in different companies the strategies differ for the branching scheme based on their specific SDLC, I believe that it is safe to say that: you should choose the strategy that better makes sense to your current workflow. Are there best practices? Surely, but remember that best practices are guidance, not orders.