Live data from Hacker News

Launch HN: Release (YC W20) – Staging environments made easy

news.ycombinator.com

21–30 of 66 posts

Re: Launch HN: Release (YC W20) – Staging environments made easy

#22

What is this with "Launch vs. Show" thing by YC incubatees lately? Is it typical "us vs. them" thinking or does YC also promote these projects on HN over others to let them appear on the frontpage much more easily?

IMO there isn't a distinction between Launch/Show, or at least one that's well understood. When we were going through our launch we asked what the difference was and didn't get a clear answer.

Did you ask me that question? There's a big difference between Show HN and Launch HN, so if I left you thinking this, it was a bad answer.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#23
There’s another YC company doing this called dockup[0] How are you guys different/better?

We tried dockup but things like DBs, authorizing Facebook and google oauth, subdomains, Stripe webhooks etc became tricky quickly. We ended up doing our own thing with docker compose and some deploy scripts. It’s a bit hairy but dockup wasn’t much cleaner either and it’s one less thing to trust (and a bit of NIH I admit)

Edit: one particular limitation of dockup that probably pushed us was the time limit on the environment. Our use case required longer running environments in some/most cases.

[0] https://getdockup.com/

Re: Launch HN: Release (YC W20) – Staging environments made easy

#24

This is what the site looks to me with Firefox: https://imgur.com/ILi5zEK This does not seem right.

We found the issue. When you have "Delete cookies and site data when Firefox is closed" set we weren't handling things correctly. Fixed and pushed. As an aside, we couldn't reproduce this locally and used an ephemeral environment to figure it out. Let me know if it works for you now.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#26
How is this different from Heroku review apps [1] besides that it's not Heroku?

We have this at work. Every PR provisions a new app with your code deployed on it. Since we use a mono-repo, we built a small Github bot that depending on Github labels sets up the right app.

[1] https://devcenter.heroku.com/articles/github-integration-rev...

Re: Launch HN: Release (YC W20) – Staging environments made easy

#27

How is this different from Heroku review apps [1] besides that it's not Heroku? We have this at work. Every PR provisions a new app with your code deployed on it. Since we use a mono-repo, we built a small Github bot that depending on Github labels sets up the right app. [1] https://devcenter.heroku.com/articles/github-integration-rev...

I think the main difference is support for complex applications (lots of services) and running in your own AWS account. We actually have a few customers who have been using Heroku Review Apps and their application has outgrown Heroku and they were bummed they were going to lose that functionality and were now faced with having to build that themselves. For companies that are just starting out or just have simple apps we think our Free and Professional plans are somewhat competitive (albeit it a little more work for now) with Heroku but we don't have the growing out of it issue.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#28
Been there done that. I would take a different route. I will start with one application and make it easy for a developer to install and run it on their computer, ideally with some dummy data. Price it as free to use, you will get tones of users. These users will need a way to get these local applications to a staging and to a production servers. Thats where you charge money and you control the entire cycle. Pulling and pushing data between live and staging sites is where the demand is and there are not many easy to use solutions.

Re: Launch HN: Release (YC W20) – Staging environments made easy

#29

There’s another YC company doing this called dockup[0] How are you guys different/better? We tried dockup but things like DBs, authorizing Facebook and google oauth, subdomains, Stripe webhooks etc became tricky quickly. We ended up doing our own thing with docker compose and some deploy scripts. It’s a bit hairy but dockup wasn’t much cleaner either and it’s one less thing to trust (and a bit of NIH I admit) Edit: o…

It’s good that multiple companies are trying to solve the problem, as it’s a big problem. I’ve not used Dockup, but from reading the docs and from other feedback I’ve heard, their solution seems like a more involved process to get running. And I think you pointed that out in your comment.

From our basic understanding of Dockup that primarily is a result of reading their documentation, it appears that the customer has to do a lot of the DevOps/AWS/Kubernetes work on their own to get things going. A big point of differentiation for us is we’re trying to automate as much of that as possible and make it accessible to developers without having to get DevOps involved (or get them involved as little as possible).

We have a solution for database and seed data that we are currently testing with customers. As far as auth'ing with 3rd parties we’ve had to solve this problem for ourselves (our integrations with Github/Bitbucket present this issue with ephemeral environments) and our approach is to take those learnings and create simple generic solutions for them. Right now we would solve that with any customer as part of our onboarding.

I’m not quite sure what challenges you had with subdomains while using Dockup. We auto-create subdomains for all your staging environments including managing dns, either in our cloud or in your AWS account. We have some documentation on how you design your architecture/app for staging environments here: https://docs.releaseapp.io/multiple-environments.

Dealing with subdomains ends up being part design issue (not hardcoding IP/host names, etc) and part using a system that can handle all the complexities around dns, and networking of your services.

We don’t have time limits on the environments. We will be adding administrative settings to allow customers to control the life-cycle of their staging environments. At this moment, they can be created manually or through a pull request. If they are created through a pull request, they are automatically removed when the pull request is merged or removed. But, this is how Release works at the moment based on customer feedback and can be adapted to your use case.

We have worked on this problem all through our careers. We are encouraged by all the companies trying to solve this issue. We feel our approach is unique in its simplicity for the end-user, but we are aware of the complexities inherent in generalizing an approach for other people. It’s hard.

I really appreciate your feedback and would love a chance to show you what we are doing and hopefully we are different and useful enough for a system as complex as yours. If you want please reach out at founders @ releaseapp .io

Re: Launch HN: Release (YC W20) – Staging environments made easy

#30
post #22

Earlier quoted context omitted.

IMO there isn't a distinction between Launch/Show, or at least one that's well understood. When we were going through our launch we asked what the difference was and didn't get a clear answer.

Did you ask me that question? There's a big difference between Show HN and Launch HN, so if I left you thinking this, it was a bad answer.

I did not. Didn't want to call anyone specifically here. Should have gone to you but didn't really pursue the question any further.
Post reply on HN