Thanks for the thoughtful reply-- I will gladly take you up on your suggestion to describe the end result we want!
- We already use terraform to manage our non-Netlify backend deployments-- servers, databases, dns configurations, etc. Terraform gives us two things that we really like/want to keep & extend
- Benefit 1: For each tier of our environment (e.g. dev, staging, pre-production, production) we know exactly what is deployed where because that configuration is checked in (i.e. the terraform repo is a documentation of our whole system).
- Benefit 2: Terraform itself keeps track of what needs to change if we edit that repo. So, if I change the SHA of the API server for the staging environment, terraform looks at our current staging environment and knows that it needs to be updated to that SHA but recognizes that our job server is current/does not need to be refreshed.
So-- what we’re looking for is SOME way to extend this type of system to our static webapp-- a complex but purely browser-based application that is frequently updated and has close connections to our api server.
We’d like not just a means of triggering new deployments via api calls or by pushing to a specific branch, but a terraform module that is smart enough to know when the current deployment is current or needs something new to happen. That smarts of detecting the difference between the code description of what’s deployed and the actual version of what’s deployed is fundamental to our workflow and our infrastructure as code goals.
Now, I’m 100% sure that given a little time and practice, we could ourselves write a new terraform module that would wrap the full-featured Netlify apis to do just this for us! That being said, we’re not a devops shop and we’ve got a long laundry list of “to dos” for our own application that mean that we’re not going to tackle this kind of project in the foreseeable future.
if we can’t find something out there that fits into our workflow, we’ll do one of two things: create some CI automation to do netlify deployments or start using some designated branches (e.g. having a branch for “pre-production” and one for “staging” etc) and just leave our front-end out of our terraform/infrastructure as code system altogether. But in either case, we’ll be losing some aspects of the workflow and inherent documentation we get by having a full-featured terraform provider that doesn’t just provision sites, but can also manage which version of our code is on the site.
I know I’ve been a little specific about HOW we use terraform here, and we’re more than willing to use another system— the key parts are that we have a way to record in code (separate from the code being deployed) what version of our apps should be currently running in each environment and that we can manage changes to that versioning via pull requests and merges to the infrastructure codebase.