That Randy Brown

Import.tf

I recently worked on a large migration of legacy infrastructure and systems configuration into terraform. One of the things that came out of it was that I kept an import file to track all the things I'd imported. Typically, I keep import statements next to the configuration for the resource imported, and usually they are removed from the code after successful import--usually in a later PR.

However, in this case, I created import.tf: a dedicated import file. I added each import to it incrementally. I can see some value to this, as it provides a record of the order of import. For instance, if one bootstraps their terraform backend, likely they will create a s3 bucket and then import that s3 bucket after the fact. This sequence of events is good to have documented, so folks in the future know how to do it.

This information can also be found in git history, for sure. And I prefer it that way. But I think it might be ignorant of existing norms and habits to think that an engineer will look in git history, rather than in code, for how to do something. Git history answers the why, typically, or in reality, in most cases, the most shallow of 'whats' (who hasn't seen a string of commits that say only fixes); the developer has to go to the code for 'how'. In this case, it makes sense to have a catalog of imports--if for no other reason than it is easier to get the blame for code that exists than for code that has been deleted.

I'm not sure if I'll continue this pattern, or if this file will hang out permanently. But I can see selective advantages when doing a migration from click ops to infrastructure as code, or for documenting processes for some standard infrastructure as code flows.