Infrastructure environment progression with Terraform - Luke Carter-Key & Simon Grzebieta

Most teams have at least one other environment where changes are tested before applying them in production where they can have either good or bad customer impact.

In various organisations we have tried several approaches to how infrastructure changes make their way to production.

We would like to share what we've learnt about the pros and cons of each approach and provide some tips on how to choose the right set of tradeoffs in different situations.

Some of these approaches are:
- Just do it in prod
- Every environment is a snowflake
- Using Terraform targeted apply to pick what to put in each environment (don't do this)
- Branches for each environment
- Directories for each environment
- Using local and remote modules to share code across environments
- Taking the same config and applying it with different tfvars to each environment

Some of these are universally a bad idea but most have situations where they are a reasonable choice.

----

[pnhbs]

10:47 - I wish there was a bit more info about this setup. How granular are we talking about for folder scope? Would there also be folders for persistence / databases, folders for IAM & security groups, each with their own state per environment? How do you handle multiple statefiles in CI/CD for this type of structure? Do you create a wrapper script that runs terraform in each directory in a particular sequence?

[weichaoluo]

Learned a lot about terraform practices in production from this video! Thanks!

[ntippy]

I took all my envs folders 10:47 out into a single large configs folder where each env file is prefixed with clusters or networks. This was done to minimize where someone must look to make a change. Often a single change needs a tweak to both clusters and networks. By putting all the config in one place it lowers the number of things the maintenance worker must know to apply the change. The ops people feel more positive that they always know where to look first.