Clearly I was wrong and clearly why you should talk to more potential customers before you make decisions. Congrats to Netlify and FeaturePeek.
It does require a bit more work to set up (which is unfortunate, since they already use the URL could they use that to map back to the PR?) but seems basically the same if not quite as polished.
That describes many of GitLab's features.
This is why I love Netlify.
They put together an incredibly powerful tool, and then released it to ALL of their customers. No, not a "Hey, we created this really cool tool! And for only an extra $3.99/mo you can utilize it!" I have several accounts, both free and paid and all of them have the Deploy Preview feature available.
There's so many things Netlify could've monetized and they haven't. They truly are a customer centric company - which is rare these days.
And that the feedback is piped into a single source of truth: GitHub (of course, if you use GitHub). It's so easy to loose track of these things when they're not near the code.
Doesn’t Heroku’s “Review Apps” predates this?
https://blog.heroku.com/heroku_review_apps_beta
(funnily enough, it’s been exactly 6 years ago today based on the beta’s blog post above)
But...there were also pipelines. A deploy preview is essentially a staging or pre-prod environment. Or going from draft to published.
Their first round was in 2012, and even though I believe they had a different product originally, their preview environment offering predated Heroku’s.
source: my last day at Heroku was a year prior to that post, and I recall using them.
If they were JavaSript only I wouldn't hold much hope, but they've been both JavaScript and Go for ages now - and I would expect Python to have a much larger user-base than Go for this.
It takes a branch in GitHub and use a config file to bootstrap the application inside a K8's cluster using a "docker in docker" model. If you could describe your infrastructure as a docker-compose.yml then you can launch it as a preview.
I'm not really a marketing person so it never went any further than a proof of concept. However, if someone is interested in working with it then I'm happy to support getting it running.
They have a few rather specific rules about it, but it works for deploy previews anyway: https://auth0.com/docs/applications/wildcards-for-subdomains
If your application itself has subdomains, Auth0 doesn’t solve this easily
My solution is to have a single callback server that looks in the OAuth state to determine where to redirect. This isn't secure, so when building the UI, I sign the UI's preview URL with a secret and send that in the OAuth state. The callback server checks the signature and redirects that way.
It's hacky and I wouldn't trust it for a production app, but for a test environment it seems okay.
