4 ms·

It's interesting to see this, a couple of months ago I was discussing this idea with a co-worker, we agreed it would be very nice to have it, but costly to buil

It's interesting to see this, a couple of months ago I was discussing this idea with a co-worker, we agreed it would be very nice to have it, but costly to build/maintain. The conclusion I got was that, we could use deterministic urls (just you like you specify `https://{repo-id}-{commit}-{service}.reploy.io` https://{repo-id}-{commit}-{service}.reploy.io`), which can get linked automatically on every PR. Every PR could trigger an environment to be created, dropping it after it's unused for a given period of time, on every commit, you could get the environment built automatically when you get an user visiting the specific url. This way, you don't waste too many resources, I wasn't able to find how similar is this to what's implemented on Reploy. Something I'd love to see, is a way to get mobile apps built for these specific environments, it's kind of simple for Android, but not so simple for iOS, so that if I'm trying a specific environment, I can run tests directly from the mobile apps prepared for it. Is there any plan to do this? or any trick to get a similar workflow? What I dislike is the price per seat, as I don't see a direct correlation between the number of Github users vs the number of environments, for small companies, it tends to increase the costs a lot, which has prevented me to integrate great tools, I'd prefer something more related to the number of active environments, so that you can choose the number that works for your team. In any case, looks promising, and of course, wish you success.

podoman 6y ago
To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed. Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users? Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing, mainly because they're hesitant about spinning up too many environments. If this seems interesting to you all, we'd be happy to chat more about pricing (as we're still figuring things out :)).
- AlexITC 6y ago
  > To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed. What about specific commits after the PR is closed? The use case I see it's to be able to easily test whether a previous commit has the same bug you are hitting in production. Then you could simulate `git bisect` on real environments. > Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users? The React Native containers idea is an interesting one, which I wasn't aware of. Related to native mobile apps, iOS/Android allow you to upload test versions, so that you can install the specific for your environment, another way for android could be to provide the APK file directly somewhere. > Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing I believe it depends on how your customers are, there are companies having decent budget for dev tools, but if you think about companies that are bootstrapping without investors, the cash available is tight, and lot's of tools to choose from. I could see myself paying $30-$60 USD/month (you mentioned $30 per seat), but that would limit it to myself, and another collaborator, It's unlikely I'm the only one in this situation.
  - podoman 6y ago
    Right now, we support branch-level commits as well. That is, you can add a specific branch that Reploy spins up environments on (in addition to open PRs). For any branch or PR that reploy is handling, you can "restart" previous commits to do comparisons. The idea for supporting any commit on the whole repo is interesting (and honestly, not hard to implement), definitely see the benefit there! Re: mobile. Yeah, maybe we could push arbitrary assets to a bucket somewhere so that you could serve an android build there. We're definitely focused on the web aspect, but this is exciting wrt/ making Reploy more encompassing. And re: pricing. Got it. If you don't mind sharing more about your team's situation, we can probably figure something out (my email's in the post). The reason we charge per seat is because its a reasonable proxy for how many environments are being spun up, and frankly we're still learning how to metricize. It'd be cool to see what your team's workflows look like.

podoman 6y ago

To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed. Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users? Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing, mainly because they're hesitant about spinning up too many environments. If this seems interesting to you all, we'd be happy to chat more about pricing (as we're still figuring things out :)).

AlexITC 6y ago
> To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed. What about specific commits after the PR is closed? The use case I see it's to be able to easily test whether a previous commit has the same bug you are hitting in production. Then you could simulate `git bisect` on real environments. > Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users? The React Native containers idea is an interesting one, which I wasn't aware of. Related to native mobile apps, iOS/Android allow you to upload test versions, so that you can install the specific for your environment, another way for android could be to provide the APK file directly somewhere. > Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing I believe it depends on how your customers are, there are companies having decent budget for dev tools, but if you think about companies that are bootstrapping without investors, the cash available is tight, and lot's of tools to choose from. I could see myself paying $30-$60 USD/month (you mentioned $30 per seat), but that would limit it to myself, and another collaborator, It's unlikely I'm the only one in this situation.
- podoman 6y ago
  Right now, we support branch-level commits as well. That is, you can add a specific branch that Reploy spins up environments on (in addition to open PRs). For any branch or PR that reploy is handling, you can "restart" previous commits to do comparisons. The idea for supporting any commit on the whole repo is interesting (and honestly, not hard to implement), definitely see the benefit there! Re: mobile. Yeah, maybe we could push arbitrary assets to a bucket somewhere so that you could serve an android build there. We're definitely focused on the web aspect, but this is exciting wrt/ making Reploy more encompassing. And re: pricing. Got it. If you don't mind sharing more about your team's situation, we can probably figure something out (my email's in the post). The reason we charge per seat is because its a reasonable proxy for how many environments are being spun up, and frankly we're still learning how to metricize. It'd be cool to see what your team's workflows look like.