googlecloudplatform / solutions-terraform-cloudbuild-gitops Goto Github PK

Currently in this repository I see the following branches:

• dev (as default)
• master
• prod

To my understanding on a strategy where we have on env per branch, we make a change on dev, if everything if fine we then create a PR promoting changes to next env, in this case prod.

1. In this case why we have master ? What purpose does it serve in the workflow?

2. Besides that I'm curious in this approach:
   How we update a value in terraform.tfvars for prod?
   Because if we need to keep branches in sync to promoted changes I guess we cannot directly commit to prod. Instead my assumption is that even if we change just a value to prod we have to actually submit it to dev and "promote" it with a PR to prod so the branches remain in sync. Is my assumption correct?

https://cloud.google.com/compute/docs/images/os-details#debian

Shouldn't it be written something like the following?

output "subnet" {
  value = "${element(module.vpc.subnets, 0).subnet_name}"
}

Currently this repo only works with legacy Terraform 0.11.x versions, it should be updated for Terraform 0.12.x.

As a good practice, the terraform.tfvars files should not be committed to source control.

In that case the CI/CD breaks, as the files are needed in the terraform init step. What would be a good strategy to avoid adding the terraform.tfvars files to source control without breaking the Cloud Build pipeline?