5-app-infra README statement about branches

[yyzh1]

TL;DR

5-app-infra/business_unit_1/ has 3 folders each with their own main.tf which should have independent resource management in different pipelines 5-app-infra/business_unit_1/development 5-app-infra/business_unit_1/non-production 5-app-infra/business_unit_1/production

However, the README instruction seems to suggest a resource change going through development->non-production->production branches for terraform plan and apply.

This should not be required as we do expect resources to largely differ between environments?

Expected behavior

The README file should suggest changes to be made inside folders where resource change intend to happen. Instead of having all resources going through the chain of development->non-production->production branches.

Observed behavior

No response

Terraform Configuration

5-app-infra/business_unit_1/

Terraform Version

N/A

Additional information

No response

[bharathkkb]

@yyzh1 Thanks for the feedback. We generally try to promote keeping the environments as similar as possible. You may notice how root config for each env is a thin wrapper around a base environment. However this is just one approach and there are alternative patterns for decoupling from this like having a single main and adopting a directory based apply pattern instead. We'd be happy to review a PR adding this info in one of our central docs and to cross link from readmes.

[yyzh1]

Thanks for the details @bharathkkb. It makes sense to use branch to separate environments, under the assumption of infrastructure similarity across environments. In the meantime, we do also have environment separation by folder, and it does not seem to make a lot of sense to mix these two approaches.

e.g. user adds a VM under "5-app-infra/business_unit_1/development" folder in a "dev" branch. when promoting the change to UAT, promoting dev branch to uat branch does not really do anything, because the "5-app-infra/business_unit_1/non-production" folder is never changed.

But if we're talking about changing the common modules inside 5-app-infra, then it probably makes sense to go through the dev->uat->prod branches.

Happy to help adding some clarification in faq , but would need some help to understand the intention of this design in terms of how it's supposed to work for the above example scenario.

[dataplex]

After spending a significant amount of time trying to figure out how 4-projects, 5-app-infra and the elusive 6-something-useful work together, I'm at a loss. We also interpreted this whole framework to be modular and extensible when it is in fact anything but modular and flexible.

The documentation is also very misleading at the onset about the option to use CloudBuild OR Jenkins, when in reality everything past step 4 assumes the organization is going to use CloudBuild and Cloud Source Repositories. Both of these products seem like they are MVP at best and did not meet the requirements my organization has around SCM and CICD security or vendor lock.

With the interpretation that we could use a Jenkins (external CICD tool) model, we replaced Jenkins in all previous steps with GitHub Actions, and are now left completely befuddled on how to proceed with GH repositories and GH Actions with this framework.

Finally, since this CFT appears to be superseded by Cloud Foundation Fabric FAST, it would have been nice for this repository and other Google documentation to acknowledge another Google supported framework out there. As far as I'm concerned, this CFT is broken for anyone except the designers who had a singular organization structure in mind when building it. Any deviation from that opinionated view of an organization quickly leads the implementer to realize there are systemic and significant flaws in the security, architecture, and process guidance presented here.

I hope someone else sees this before they start down this road so they can avoid the days and weeks it takes a team to push down this path under the guise that it's the best Google could come up with before realizing they wasted all that time.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days