5 ms·

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 Ap

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?

podoman 6y ago
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?
- sergiomattei 6y ago
  > 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?
  - podoman 6y ago
    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.
    - josegonzalez 6y ago
      I believe a Procfile on Heroku is used for Dockerfile-based apps, though the `heroku.yml` takes precedence if that is available.
Ozzie_osman 6y ago
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.
- podoman 6y ago
  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 ^^)
lojack 6y ago
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.
- Ozzie_osman 6y ago
  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.
iRomain 6y ago
The name’s Reploy not Deploy
- podoman 6y ago
  True that! At Reploy, we spin up Reployments, not Deployments! :)

podoman 6y ago

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?

sergiomattei 6y ago
> 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?
- podoman 6y ago
  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.
  - josegonzalez 6y ago
    I believe a Procfile on Heroku is used for Dockerfile-based apps, though the `heroku.yml` takes precedence if that is available.

Ozzie_osman 6y ago

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.

podoman 6y ago
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 ^^)

lojack 6y ago

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.

Ozzie_osman 6y ago
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.

iRomain 6y ago

The name’s Reploy not Deploy

podoman 6y ago
True that! At Reploy, we spin up Reployments, not Deployments! :)