This pull request splits our current "monolithic" Terraform state into separate workspaces, which lets us safely apply changes to environments selectively (for example, testing a change to a shared module in dosomething-dev before applying in production).
This splits our single infrastructure workspace into 9 independent workspaces:
I have not updated the three dosomething- modules to import the pipeline variable from the shared pipeline yet, just to keep this a bit more contained (instead, these are just a variable for each workspace with the Pipeline ID).
How should this be reviewed?
Yikes!!! 🐳 This is not quite as overwhelming as it looks – the bulk of the diff comes from moving files that were referenced outside of the "module path" into each module where they're referenced (since you can't just grab files recklessly between workspaces anymore).
The other big change is moving backend & provider configuration into each module (e.g. from the single main top-level module into dosomething, dosomething-qa, etc). This is nice since it means we can test newer provider versions on dev/QA before using on production!
If you click to expand the "checks" at the bottom of this PR, you can see that this introduces no new changes:
Any background context you want to provide?
Moving resources between workspaces is incredibly awkward (hopefully improvements are on the Terraform roadmap!): you can either terraform import each one from scratch, or you can terraform state pull the state down to a file & terraform state mv each resource into a "fresh" state file that you can then terraform state push to the new workspace.
I opted for the second approach, but it was still way more tedious than I'd have expected!
What's this PR do?
This pull request splits our current "monolithic" Terraform state into separate workspaces, which lets us safely apply changes to environments selectively (for example, testing a change to a shared module in
dosomething-devbefore applying in production).This splits our single
infrastructureworkspace into 9 independent workspaces:dosomething-prod,dosomething-qa, anddosomething-devfor our core applications. In the future, these can be consolidated into one singledosomethingthat we promote between workspace stages (and customize via environment variables in each stage).longshot(with our old Longshot application resources)quasar(which has Quasar & Quasar QA resources… should be split in the future!)redirects(with our two Fastly "domain redirect" properties)voting-app(with the old Athletes Gone Good static site)vote-instapage(with the Fastly wrapper aroundvote.dosomething.org)shared(with Heroku pipelines & CircleCI credentials)I have not updated the three
dosomething-modules to import the pipeline variable from thesharedpipeline yet, just to keep this a bit more contained (instead, these are just a variable for each workspace with the Pipeline ID).How should this be reviewed?
Yikes!!! 🐳 This is not quite as overwhelming as it looks – the bulk of the diff comes from moving files that were referenced outside of the "module path" into each module where they're referenced (since you can't just grab files recklessly between workspaces anymore).
The other big change is moving backend & provider configuration into each module (e.g. from the single
maintop-level module intodosomething,dosomething-qa, etc). This is nice since it means we can test newer provider versions on dev/QA before using on production!If you click to expand the "checks" at the bottom of this PR, you can see that this introduces no new changes:
Any background context you want to provide?
Moving resources between workspaces is incredibly awkward (hopefully improvements are on the Terraform roadmap!): you can either
terraform importeach one from scratch, or you canterraform state pullthe state down to a file &terraform state mveach resource into a "fresh" state file that you can thenterraform state pushto the new workspace.I opted for the second approach, but it was still way more tedious than I'd have expected!
Relevant tickets
References Pivotal #170776057.
Checklist