Agree that "preview apps are hard" is a massive bottleneck - especially when specs are evolving and a feature may spend some time being QA'd by technical and non-technical team members before being ready to land. Not to mention that processes for securely populating seed data from recent production data are highly domain-specific!
We've built our own system for preview apps on k8s, with a complex Github action that tries to encapsulate everything we can into a set of helm charts that are installed into a dedicated namespace for all the databases and services for that specific PR.
Of course, this can only go so far, and doesn't easily allow for tracking assets outside of k8s. But given that we can keep many of those shared, we've in part stayed away from Terraform due to adding yet another learning curve - but also for lack of tooling for this shared-some-things-but-not-all per-environment customizability - the exact problem you're solving!
I'm excited to see where this system goes - and am excited to see what value-add layers you build on the UI and governance/cost-control side!
Thanks! We really appreciate the in-depth feedback.
Indeed, we've seem many people building similar alternatives using in-house solutions on top of Kubernetes. In fact, that's the main barrier to adoption we've found so far.
The Terraform point is really interesting. In our earlier solution we tried to use compose files because we thought they'd be easier to implement. In reality what happened was that most people couldn't use it because they had more complex infra (or at least _wanted_ to have more complex infra) in their previews.
Especially after the whole TF situation we'll probably be looking into other ways to configure it anyway.
Agree that "preview apps are hard" is a massive bottleneck - especially when specs are evolving and a feature may spend some time being QA'd by technical and non-technical team members before being ready to land. Not to mention that processes for securely populating seed data from recent production data are highly domain-specific!
We've built our own system for preview apps on k8s, with a complex Github action that tries to encapsulate everything we can into a set of helm charts that are installed into a dedicated namespace for all the databases and services for that specific PR.
Of course, this can only go so far, and doesn't easily allow for tracking assets outside of k8s. But given that we can keep many of those shared, we've in part stayed away from Terraform due to adding yet another learning curve - but also for lack of tooling for this shared-some-things-but-not-all per-environment customizability - the exact problem you're solving!
I'm excited to see where this system goes - and am excited to see what value-add layers you build on the UI and governance/cost-control side!