Context = Terraform mandatory everywhere, even in dev.
So that teams can work on infra in parallel and not in series in dev, I’m tempted to recommend the ‘-target’ option on a massive scale in dev (Target resources | Terraform | HashiCorp Developer) combined with modules.
The terraform documentation indicates that “Targeting individual resources can be useful for troubleshooting errors, but should not be part of your normal workflow.”. I don’t recommend this option in uat / prod.
It doesn’t mean you don’t have to split things up into several states, but sometimes 3 developers work on 3 different resources. Plus when you work with terraform entreprise, billing is a function of the number of workspaces (ie states).
Is it shocking to use ‘-target’ on a daily basis in dev?
I don’t recommend using the -target option as a standard practice. This can lead to inconsistencies in your state file, with a high chance that it won’t fully match the real environment.
There’s also a risk that someone might run an apply without -target, potentially undoing some changes.
Additionally, depending on the number of linked resources, updating each resource individually can be difficult, and indirect dependencies may also become inconsistent. If there’s a change with -target that recreates the resource, it will inevitably cause dependency inconsistencies.
Another point is that if you have any resources created with a loop (using for_each or count), updating them with -target would require targeting each item in the loop separately.
What would be the main issue that would make you consider using -target in dev? Locking during the apply?
I would say first, think about if there are ways to work on the state layout so that these sorts of collisions are less frequent or less likely. Finding the optimal balance is not always easy, and it’s not a “one-size fits all” kind of situation – it depends how your applications and teams are structured, the size of the company, etc, and there are always tradeoffs with having narrower or wider scopes of states.
I would also take a look at what your approval / plan / apply workflow looks like, and see if there are ways to reduce the time between “apply” and “merge”. At that point, having an additional locking layer (like the one Atlantis provides, let’s say, or TFE, as in your suggestion) may also be a good idea.
I don’t know if I’d say it’s shocking, but I can say that I’ve successfully worked at various sizes of organization without -target being a frequent occurrence.