What’s the typical workflow for including for only defining resources depending on context, like an environment (prod vs. test)? Variables? Workspaces? Modules? My main use case is prod vs. test environments, test may have some resources that will not exist in production. I’m using GCP, so for example, I need maybe 3 or 4 static IP addresses in my test GCP project (e.g. project-test) and in production (e.g. project-prod) I will need only 2 static IP address.
Thanks for the video. Multiple environment approach works great with one main.tf, is there any better approach if we have one main.tf for each modules/resources like AKS, Keyvault etc?
One TF file per resource would be also nice. I see also some companies splitting these resources across different tf state files to not break the monolithic tf state.
Thank you Houssem, was searching this for a day reached here with better approach of dealing with multiple environments.
Thank you Houssem! I had gotten your CI/CD course in Udemy already. I happened to stumble on this video!
Great! Thanks!
Thank you, keep up the good work!
Thank you 😊
Thank you... great content! :)
Very nicely done to compare with and without workspace the difference. 5 stars
Each workspace will have different state file
What’s the typical workflow for including for only defining resources depending on context, like an environment (prod vs. test)? Variables? Workspaces? Modules? My main use case is prod vs. test environments, test may have some resources that will not exist in production. I’m using GCP, so for example, I need maybe 3 or 4 static IP addresses in my test GCP project (e.g. project-test) and in production (e.g. project-prod) I will need only 2 static IP address.
Hi , I understand that workspace in terraform is not a good solution to manage multiple env. But, which scenario this workspace will give the best
Thanks for the video. Multiple environment approach works great with one main.tf, is there any better approach if we have one main.tf for each modules/resources like AKS, Keyvault etc?
One TF file per resource would be also nice. I see also some companies splitting these resources across different tf state files to not break the monolithic tf state.