I developed something like this for my frontend team at a previous company as well. Much needed and I'm surprised not already mainstream. Love the focus on privacy/security.
What's the difference from https://featurepeek.com/?
Show HN: PullPreview – Deploy previews for any application, on your servers
11–20 of 38 posts
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#12Wow this is cool. I actually spent a lot of time developing a solution for this for the last company I worked for. I copied the Angular repos way of doing it. https://github.com/angular/angular/blob/master/aio/aio-build... It's really well documented and made the whole process a lot less work. It works great for angular apps. There doesn't seem to be a ton of services in this space and for larger teams working on the…
Hello, thanks for your comment!
I had a look at the angular way of doing it: very nice to see other approaches! From a quick look it does seem to require quite a bit more steps and to be more limited in scope, but the documentation looks very good indeed! Thanks for sharing!
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#13I developed something like this for my frontend team at a previous company as well. Much needed and I'm surprised not already mainstream. Love the focus on privacy/security. What's the difference from https://featurepeek.com/ ?
I didn’t know about FeaturePeek, thanks for mentioning. It looks very similar indeed. From a quick look I would say the main differences are that it doesn’t run on servers you control, and is limited to frontend code only?
Also it’s pretty expensive with their per-seat pricing ;)
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#14This is pretty neat. Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. If containers are a focus perhaps you could support k8s deployment/svc manifests and compose via something like https://github.com/kubernetes/kompose For k8s you could quickly launch a single node cluster with kind
> Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose.
Actually the way it works now is that you keep the same server for the duration of a PR / branch. This means faster redeploys since the docker cache is there, and you don’t lose your demo data on every redeploy.
Cloud-init is used for the initial setup of docker and compose, but then the code sync happens through sending the app tarball from GitHub to the server and refreshing the compose.
We thought about mono-node k8s, but found that removing one abstraction layer would be better for now.
Thanks for your comment!
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#15This is pretty neat. Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. If containers are a focus perhaps you could support k8s deployment/svc manifests and compose via something like https://github.com/kubernetes/kompose For k8s you could quickly launch a single node cluster with kind
> Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. Actually the way it works now is that you keep the same server for the duration of a PR / branch. This means faster redeploys since the docker cache is there, and you don’t lose your demo data on every redeploy. Cloud-init is used for the initial setup of docker and compose, but then the code sync…
Interesting and nice design on the hot deploy, lots of potential there. Congrats on shipping!
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#16Earlier quoted context omitted.
> Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. Actually the way it works now is that you keep the same server for the duration of a PR / branch. This means faster redeploys since the docker cache is there, and you don’t lose your demo data on every redeploy. Cloud-init is used for the initial setup of docker and compose, but then the code sync…
Interesting and nice design on the hot deploy, lots of potential there. Congrats on shipping!
Yep, it’s also not limited to GitHub in any way and could be used straight from your dev machine or from other CI tools such as GitLab CI, Circle, Jenkins, etc.
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#17Hi HN, this is our submission for PullPreview, a way to spin preview environments for any application directly from GitHub to cheap AWS Lightsail servers. No intermediary service involved. ## Context PullPreview’s main use case is for making it easier to review code in branches or pull requests, because reviews with live code are always better than code-only reviews. This means better and faster feedback from reviewe…
Also, something we didn’t mention on the site but might be interesting for some people: we’re more than happy to provide guidance and consulting on how to migrate your app to Docker Compose if that could be a blocker. Think of it as a kind of Concierge service. Don’t hesitate to send an email if you might be interested.
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#18Looks good guys, it's definitely a tricky problem to solve well. I've written a similar open source version of this which you can find here:
https://gitlab.com/Rodeoclash/StageHand
I went with a similar idea of using Docker Compose to configure the app although with an extra layer on top of that to be able to expose multiple services. I wanted both the application itself and the ability to say, view the database using PGWeb while I interacted with it. You can see this in the screenshots in the link and I think this is quite a powerful feature as it allows you (in our case) to catch outgoing emails for example.
I never really got around to writing good documentation for standing up the service as it's quite complicated, but if anyone is interested I could help you through it.
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#19Looks good guys, it's definitely a tricky problem to solve well. I've written a similar open source version of this which you can find here: https://gitlab.com/Rodeoclash/StageHand I went with a similar idea of using Docker Compose to configure the app although with an extra layer on top of that to be able to expose multiple services. I wanted both the application itself and the ability to say, view the database usin…
Hello, review apps are a hot topic it seems ;)
Many companies have come with their own version of the concept, which in our experience doesn’t stand well the test of time (because the person that wrote the glue code left the company or docs are lacking or setup is very complex, etc). Hence PullPreview, so that companies can delegate the burden of maintaining that workflow to us, while retaining full control over their code and servers.
Our version is also Open Source (but not free except for non profits) and it doesn’t limit in any way the number of ports you can expose . By default and for ease of use ports 22, 80 and 1000-10000 are allowed in the firewall, but you can reduce that to the bare minimum with just a single config option. See https://github.com/pullpreview/action/wiki/Inputs For more details.
Re: Show HN: PullPreview – Deploy previews for any application, on your servers
#20Looks good guys, it's definitely a tricky problem to solve well. I've written a similar open source version of this which you can find here: https://gitlab.com/Rodeoclash/StageHand I went with a similar idea of using Docker Compose to configure the app although with an extra layer on top of that to be able to expose multiple services. I wanted both the application itself and the ability to say, view the database usin…
Hello, review apps are a hot topic it seems ;) Many companies have come with their own version of the concept, which in our experience doesn’t stand well the test of time (because the person that wrote the glue code left the company or docs are lacking or setup is very complex, etc). Hence PullPreview, so that companies can delegate the burden of maintaining that workflow to us, while retaining full control over thei…
Awesome!
It's always interesting to see how others solve the curly edge cases too. I struggled with figuring out when to shut down a preview (hence why it deploys in an iFrame, I track presence using websockets and shut the preview down after the user is done)
Deploying on Lightsail is good too. I went with K8s and always had the intention of using some kind of VM level isolation, but (kind of) physically separate servers like Lightsail works well too.
Why thing I couldn't really figure out, how do you go with large docker images? The bulk of my spin up time is spent pulling the image. I never got around to figuring out how to do a good cache for it.