A year or so ago I was working on a similar product as FeaturePeek - a platform agnostic deploy preview and collaboration tool. I decided not enough people would want that outside of their hosting platform and shelved it.
Clearly I was wrong and clearly why you should talk to more potential customers before you make decisions. Congrats to Netlify and FeaturePeek.
To be fair to yourself this is probably a lot more than a year's work, but also... just because it exists doesn't mean that another shouldn't version shouldn't exist either!
Unless you have inside information on the terms of the acquisition, I wouldn't beat yourself up about what might have been. There's a very broad spectrum of options here between "we like the team and have agreed to put them on payroll because it's cheaper and faster than using recruiters" to "F$%@ you money for the founders". We've no way to know which it is.
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.
Collaborative Deploy Previews are fully enabled on every Netlify account today! Anyone with a Netlify account can use the reviewer tool.
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.
This is awesome! I love that everyone can now give feedback. Developers, designers, people who write copy, etc.
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.
I remember using ephemeral Heroku deploys in the dev pipeline well before I knew Netlify was a thing. That was pretty much the last major innovation I saw from Heroku, before Salesforce decided they'd grown fat enough to milk.
But...there were also pipelines. A deploy preview is essentially a staging or pre-prod environment. Or going from draft to published.
There was a company called Runnable that had a product offering, but if I recall correctly was acquired by MuleSoft and shut down.
Their first round was in 2012, and even though I believe they had a different product originally, their preview environment offering predated Heroku’s.
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.
We have a deploy preview system at work and it is so valuable. I see less value in the collaboration tools built on top of these previews, but it’s cool nonetheless.
I ran into this issue when setting up UI previews for a GitHub OAuth app.
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.
This looks great and all but the new drawer icon covers up a key button on our app.. ironically the person who noticed took a regular screenshot and shared it in slack
quaffapint|4 years ago
Clearly I was wrong and clearly why you should talk to more potential customers before you make decisions. Congrats to Netlify and FeaturePeek.
mynegation|4 years ago
pistoriusp|4 years ago
glenngillen|4 years ago
kevincox|4 years ago
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.
kenrose|4 years ago
That describes many of GitLab's features.
sytse|4 years ago
at-fates-hands|4 years ago
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.
esilverman|4 years ago
elitan|4 years ago
swyx|4 years ago
ridruejo|4 years ago
pistoriusp|4 years ago
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.
HatchedLake721|4 years ago
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)
p0deje|4 years ago
ljm|4 years ago
But...there were also pipelines. A deploy preview is essentially a staging or pre-prod environment. Or going from draft to published.
nrmitchi|4 years ago
Their first round was in 2012, and even though I believe they had a different product originally, their preview environment offering predated Heroku’s.
glenngillen|4 years ago
source: my last day at Heroku was a year prior to that post, and I recall using them.
tin7in|4 years ago
simonw|4 years ago
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.
Rodeoclash|4 years ago
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.
kennyIO|4 years ago
bigyikes|4 years ago
robertlagrant|4 years ago
ccheney|4 years ago
fishtoaster|4 years ago
They have a few rather specific rules about it, but it works for deploy previews anyway: https://auth0.com/docs/applications/wildcards-for-subdomains
MapleWalnut|4 years ago
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.
armincerf|4 years ago