5 ms·

Hi 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 in

by crohr 6y ago

Hi 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 reviewers (be it clients or teammates), so that everyone can iterate faster on the feature being developed. However in most organizations, there is only a handful of staging servers available to the developers, which are hard to keep in sync, maintain, and with complicated processes to make sure you don’t step on someone else’s code. PullPreview solves this with ephemeral environments for any pull request or branches, just by adding a label from the GitHub UI. URLs for the deployed environments are displayed right into the GitHub UI, thanks to the integration with the Deployments API. ## How it works (spoiler: no kubernetes) Contrary to many other solutions, PullPreview _never sees your code_, because it runs as a GitHub Action and does all the work within the GitHub Action runner. The Action automatically provisions a server in _your_ AWS account (a cheap Lightsail instance), and then boots your application using the Docker Compose file(s) that you specify. The server is automatically destroyed when the PR is merged, closed, or the label removed. Some of the features include unlimited parallel environments, support for SSH access, source IP filtering, port filtering, seed data support, data persistence across deploys, all managed from the GitHub UI. All of this is packaged as an Open-Source GitHub Action that can be tried right now. You can run it for free for 30 days, and after that we have two license tiers at 120€/year and 300€/year. We believe it is pretty cheap compared to rolling and maintaining your own solution in-house. It is also free for non-profits. ## Next steps We’re looking for feedback on the idea, what could be missing, and the pricing. We are also discovering many more use cases while dogfooding our own idea. For instance, we are currently running a few services in production, continuously deployed thanks to PullPreview (e.g. pullpreview.com itself).

redis_mlc 6y ago
> because reviews with live code are always better than code-only reviews. Always? I don't know. The author is responsible for testing and deploying the PR, not the reviewer. Also, in devops a lot of changes affect production, so cannot be fully tested until deployment. It sounds useful for seeing UI changes, but the closer you get to the backend, the less visibility there is. Or in companies with "political issues" like multiple groups with boundaries between development, test, and operations. Maybe the PullReview people can add some use cases?
- crohr 6y ago
  Hi, thanks for commenting! The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the development process. It’s particularly useful for product owners who may not be coders and want to give feedback on how the feature aligns with the vision. It’s also useful for other developers because seeing the thing live will give more context as to what the feature does and how it behaves, and as such might help reviewing the code and get reviews other than « good to merge » without any meaningful comments. And finally it’s also very useful in making sure every dev can do a little QA on their feature in a standardised environment that runs with non-dev setting, without waiting for a staging server to be available. The 80/20 rule most likely applies here. For some PRs you won’t need preview environments (just don’t add the label), but from my consulting gigs I have experienced more than once the need for this kind of tooling, and also witnessed more than once how many companies try to reinvent their own thing and the time they spend/waste doing so.
crohr 6y ago
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.
nrmitchi 6y ago
First off, congrats on launching! I've personally been working on something very similar for the last bit, and actually plan on launching very soon. As other commenters have mentioned, this is a system which seems all-to-common to have built in house, and I think you've highlighted issues with that: it may be simple to get something basic working, but without a larger investment, it ends up being unstable and unmaintained. It's been great seeing all of the similar solutions being launched over the past month, and the slight different ways that different players (you, Okteto, LayerCI, Release, FeaturePeek, etc) are approaching this issue. I see that what you have done is specifically focused on Docker, and purposely avoided Kubernetes. I think that gives you a niche space, along with Dockup (https://getdockup.com/ https://getdockup.com/), who I believe are taking the same approach. I appreciate your focus on security and privacy, specifically around "can never seen your code", but I'm curious about this choice. Did you find that this was actually a concern that customers had? CI/CD platforms, which are kind of a neighbor of Continous Product Review tools (this is how I've been referring to this class of product internally), and have an implicit trust. I have not received much push-back about automated code access, and when that has been a concern, I've found that those individuals preferred to how everything in-house anyways (Gitlab, or Github Enterprise). Do you have any sort of cost-control structure in place? Being a Github Action, I see this more as a library than a managed service, which also means you have less control/ability to monitor your users ephemeral environments, and I would hate to see the shutdown behaviour break, and suddenly ephemeral environments never go away and your user is left with an obnoxiously large AWS bill. Overall, I love what you're doing to approach this space in a new way. If you'd like to chat about the space, my email is in my profile (I literally just added it, so hopefully it's visible :fingers-crossed:)
- crohr 6y ago
  Hello, thanks for your comment and the great points you’ve made. Regarding security, we do believe that it is a selling point for many companies. You might be ok granting access to Circle CI or others, but for a new kid on the block that’s more difficult. And being run as a self contained action means you are not dependent on the availability or continuity of the service you depend on. As for misbehaving instances, this is indeed something that we thought about, and we’ll make sure this doesn’t happen in two ways: - allowing to set a max duration for an instance, and a max number of concurrent instances - having an additional trigger in the workflow file to launch a cleanup phase like every day, since GitHub actions already support cron-like tasks I’ll send you an email a bit later as I’m currently on the go, thanks again and talk to you soon!
GordonS 6y ago
This looks pretty nice, though it seems this is a rapidly crowding space (although I didn't know there were any such tools until your post!). Something I'm wondering about is how other cloud services fit into all this though - for example, messaging services, event streaming services, blob storage, table storage, databases etc?
- crohr 6y ago
  Hello! The first recommendation would be to find a docker image providing a mock for the service you want (e.g. [1]) and if not enough then you could provision those services on demand in an additional step executing before the pullpreview step in the GitHub Action workflow file. [1] https://github.com/localstack/localstack https://github.com/localstack/localstack

by crohr 6y ago

redis_mlc 6y ago

> because reviews with live code are always better than code-only reviews. Always? I don't know. The author is responsible for testing and deploying the PR, not the reviewer. Also, in devops a lot of changes affect production, so cannot be fully tested until deployment. It sounds useful for seeing UI changes, but the closer you get to the backend, the less visibility there is. Or in companies with "political issues" like multiple groups with boundaries between development, test, and operations. Maybe the PullReview people can add some use cases?

crohr 6y ago
Hi, thanks for commenting! The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the development process. It’s particularly useful for product owners who may not be coders and want to give feedback on how the feature aligns with the vision. It’s also useful for other developers because seeing the thing live will give more context as to what the feature does and how it behaves, and as such might help reviewing the code and get reviews other than « good to merge » without any meaningful comments. And finally it’s also very useful in making sure every dev can do a little QA on their feature in a standardised environment that runs with non-dev setting, without waiting for a staging server to be available. The 80/20 rule most likely applies here. For some PRs you won’t need preview environments (just don’t add the label), but from my consulting gigs I have experienced more than once the need for this kind of tooling, and also witnessed more than once how many companies try to reinvent their own thing and the time they spend/waste doing so.

crohr 6y ago

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.

nrmitchi 6y ago

First off, congrats on launching! I've personally been working on something very similar for the last bit, and actually plan on launching very soon. As other commenters have mentioned, this is a system which seems all-to-common to have built in house, and I think you've highlighted issues with that: it may be simple to get something basic working, but without a larger investment, it ends up being unstable and unmaintained. It's been great seeing all of the similar solutions being launched over the past month, and the slight different ways that different players (you, Okteto, LayerCI, Release, FeaturePeek, etc) are approaching this issue. I see that what you have done is specifically focused on Docker, and purposely avoided Kubernetes. I think that gives you a niche space, along with Dockup (https://getdockup.com/ https://getdockup.com/), who I believe are taking the same approach. I appreciate your focus on security and privacy, specifically around "can never seen your code", but I'm curious about this choice. Did you find that this was actually a concern that customers had? CI/CD platforms, which are kind of a neighbor of Continous Product Review tools (this is how I've been referring to this class of product internally), and have an implicit trust. I have not received much push-back about automated code access, and when that has been a concern, I've found that those individuals preferred to how everything in-house anyways (Gitlab, or Github Enterprise). Do you have any sort of cost-control structure in place? Being a Github Action, I see this more as a library than a managed service, which also means you have less control/ability to monitor your users ephemeral environments, and I would hate to see the shutdown behaviour break, and suddenly ephemeral environments never go away and your user is left with an obnoxiously large AWS bill. Overall, I love what you're doing to approach this space in a new way. If you'd like to chat about the space, my email is in my profile (I literally just added it, so hopefully it's visible :fingers-crossed:)

crohr 6y ago
Hello, thanks for your comment and the great points you’ve made. Regarding security, we do believe that it is a selling point for many companies. You might be ok granting access to Circle CI or others, but for a new kid on the block that’s more difficult. And being run as a self contained action means you are not dependent on the availability or continuity of the service you depend on. As for misbehaving instances, this is indeed something that we thought about, and we’ll make sure this doesn’t happen in two ways: - allowing to set a max duration for an instance, and a max number of concurrent instances - having an additional trigger in the workflow file to launch a cleanup phase like every day, since GitHub actions already support cron-like tasks I’ll send you an email a bit later as I’m currently on the go, thanks again and talk to you soon!

GordonS 6y ago

This looks pretty nice, though it seems this is a rapidly crowding space (although I didn't know there were any such tools until your post!). Something I'm wondering about is how other cloud services fit into all this though - for example, messaging services, event streaming services, blob storage, table storage, databases etc?

crohr 6y ago
Hello! The first recommendation would be to find a docker image providing a mock for the service you want (e.g. [1]) and if not enough then you could provision those services on demand in an additional step executing before the pullpreview step in the GitHub Action workflow file. [1] https://github.com/localstack/localstack https://github.com/localstack/localstack