Hacker News Reader

Comment by giovannibonetti | Hacker News Reader

Here comes the elephant in the room. Please take it kindly since I'm trying to make constructive feedback.

In my company we have been using: - Heroku Review Apps for the back-end - built with Rails, each branch/app has a separated (tiny) database - Vercel (formerly Zeit) for the front-end, which is very fast and each commit generates a separated app - which is great for comparing changes.

Important: both of these platforms allow you to run review apps for free (as in free beer) for a small team.

With that context, what advantage is there on using Deploy instead of any of these platforms?

View on HN

We use Heroku Review Apps as well. We are considering moving to AWS, and one thing that was holding us up was that setting up review apps in AWS would require some extra work (it's not impossible but definitely not as easy as Review Apps). So I can definitely see how a tool like this can have value if you're _not_ on Heroku.

Thanks for chiming in. We're also looking to offer more than Heroku does w/ their Review apps feature :). I actually learned that the Procfile was a semi-standard on this thread, so maybe a move from Heroku isn't too difficult.

Also, happy to chat more if you're interested in the product, let me know! (you have my email ^^)

We're using Heroku where I'm at and looking to move off of it for a number of reasons. Review apps are one of the great things about Heroku, but once your team is above a certain size its most definitely not free, or even cheap.

The biggest pain point I'd like to see solved (beyond just review apps) is the provisioning of good staging data. Ultimately we want data that looks like a subset of production data with PII scrubbed. Heroku doesn't give you an easy mechanism for getting this, and we had to sink a ton of time building this out for our specific use case.

YMMV, depending on your data. What we do is maintain a default staging environment and a prod environment. They are both continuously deployed off of master, so it's the same code, and we have staging populated with data that is similar to prod (just without real users... So it's just employees using it).

When we spin up a review app, it generates a backup of the staging db, restores it to the review app environment. That way all review apps have essentially a copy of the default staging data. That command (backup and restore for postgres) is like two lines of code.

No worries, we like feedback!

So to touch on the Heroku argument, its easy for your team to set this up because your production environment is already on Heroku. For teams that deploy on AWS, however, setting up a `reploy.yml` file and committing it is arguably easier than dealing with Procfiles.

Re: Vercel, if a team only needs frontend apps, its definitely a good option. We offer the same service in this sense.

Overall, in your case, I do see a benefit in having both of these solutions combined. That is, being able to restart or compare a PR's state in one system probably adds value?

> arguably easier than dealing with Procfiles

This is quite a strong statement — I've never had an issue with procfiles, and prefer them considering how easy they make process management. They're also even semi-standard, considering that multiple services use them (Heroku, AWS EB, etc) - contrary to the reploy.yml file.

What are the issues you've noticed with them?

This is more of a subjective thought, but we use docker under the hood, so we support any arbitrary docker containers. Procfiles are limited in that sense.

But the argument that if you already have Procfiles in place, its easier, makes a lot of sense.

I believe a Procfile on Heroku is used for Dockerfile-based apps, though the `heroku.yml` takes precedence if that is available.

The name’s Reploy not Deploy

True that! At Reploy, we spin up Reployments, not Deployments! :)

Reply on news.ycombinator.com