4 ms·

Wait… different branches for different environments? Wouldn’t you run into the same problems?

officialchicken 5y ago
Not really, but it depends on what the repo represents. Not all envs can be identical despite the logical preference - non-wildcard SSL certs for example. I think the author here is referring to an infrastructure repo with branch-per-env as a common pattern for devops / IaaC / terraform code bases, versus env-per-folder or similar in the trunk if you absolutely have to have differences between envs. It mentions deploying build artifacts from a parallel CI/CD at the end of the article for running the software running on the infra.
jb_s 5y ago
Yes. I personally prefer having IaC in the same repo as the code. Any changes to the code OR the IaC uses the git flow as per normal and requires a PR. When the PR is merged to develop its pushed to QA environments automatically - therefore updating infrastructure with the updated IaC. We update deployment configuration separately (because why would we include anything environment-specific in the repo?), this never presents any major issues although sometimes I guess you'd need to update the config just at the same time as merging the code PR which is slightly inconvenient and is somewhat OCD triggering, but its a productive setup so I don't mind.
- steveBK123 5y ago
  My orgs problem is that the IaC is owned by different people than the apps code running on the infra the IaC controls. Much fun ensues in trying to have any sense of a predictable timeline when you want to rollout any app feature requiring IaC changes. Feels worse than on-prem datacenter work cuz at least there the team was bigger, and it was slow, but mature with a ticketing system, SLAs and no key man dependencies. With someone-else-owns-myIaC, I am dealing with 2-3 DevOps dudes who kind of sort of use Jira sometimes, and lack staff in some of the region timezones our business operates in.

Not really, but it depends on what the repo represents. Not all envs can be identical despite the logical preference - non-wildcard SSL certs for example. I think the author here is referring to an infrastructure repo with branch-per-env as a common pattern for devops / IaaC / terraform code bases, versus env-per-folder or similar in the trunk if you absolutely have to have differences between envs. It mentions deploying build artifacts from a parallel CI/CD at the end of the article for running the software running on the infra.

jb_s 5y ago

Yes. I personally prefer having IaC in the same repo as the code. Any changes to the code OR the IaC uses the git flow as per normal and requires a PR. When the PR is merged to develop its pushed to QA environments automatically - therefore updating infrastructure with the updated IaC. We update deployment configuration separately (because why would we include anything environment-specific in the repo?), this never presents any major issues although sometimes I guess you'd need to update the config just at the same time as merging the code PR which is slightly inconvenient and is somewhat OCD triggering, but its a productive setup so I don't mind.

steveBK123 5y ago
My orgs problem is that the IaC is owned by different people than the apps code running on the infra the IaC controls. Much fun ensues in trying to have any sense of a predictable timeline when you want to rollout any app feature requiring IaC changes. Feels worse than on-prem datacenter work cuz at least there the team was bigger, and it was slow, but mature with a ticketing system, SLAs and no key man dependencies. With someone-else-owns-myIaC, I am dealing with 2-3 DevOps dudes who kind of sort of use Jira sometimes, and lack staff in some of the region timezones our business operates in.