My company build something pretty identical to this a few years ago. It's INVALUABLE if you have a QA team or non-tech people who need to test things on different branches. Our workflow basically went like this:<p>1. Dev pushes branch to repo
2. Dev assigns ticket to QA
3. QA builds a sandbox server
4. QA tests everything under the sun
5. Any bugs are pushed to repo and auto-pushed to sandbox server
6. After QA gives green light, sandbox server is taken down.<p>Average uptime for a sandbox server was a few hours, and we caught a bazillion bugs this way. I'm no longer with that company, so it's really exciting that someone else has built something like this off-the-shelf so that I can continue with that workflow at future jobs. :)
This looks great, thanks for sharing -- I was planning to write something like this for my build pipeline, but having something available off-the-shelf will save a lot of time.<p>Eventually I'll be moving our Docker containers to run under Kubernetes, which might necessitate writing my own thing to replace this; I'd ultimately like to be able to deploy my k8s config files into a per-branch/per-commit namespace, so that the full deploy pipeline can be tested.
This is really a great idea, imo. At my last gig we had four projects in GCP using kubernetes to deploy various clusters, and essentially all but one of those projects were for testing branches. Will be keeping an eye on this.
Any plans to include Bitbucket repositories?<p>Bitbucket offers a more favorable pricing policy for development agencies, which would potentially be heavy users of your service.
This looks very similar to what is offered by <a href="https://platform.sh/" rel="nofollow">https://platform.sh/</a> . Anybody familiar with both could contrast them?
Sounds a lot like Heroku review apps[1]<p>1: <a href="https://devcenter.heroku.com/articles/github-integration-review-apps" rel="nofollow">https://devcenter.heroku.com/articles/github-integration-rev...</a>
How would this look like when multiple branches from different projects work together?<p>> Developers can pull individual components or services locally and connect to the rest of the stack on Runnable.<p>This sounds great, I wonder how this is done.<p>I am currently evaluating docker-cloud for the same purpose since all of our infrastructure is Dockerized. Can you comment on the differences?
Really cool. I actually hand rolled my own solution using a Node CLI and the AWS API.<p>What features/problems does Runnable solve over <a href="https://elasticbox.com" rel="nofollow">https://elasticbox.com</a>?<p>Also, who did your promo video <a href="https://www.youtube.com/watch?v=mBR-_5dXH4w&feature=youtu.be" rel="nofollow">https://www.youtube.com/watch?v=mBR-_5dXH4w&feature=youtu.be</a>)? They did an amazing job.
On pricing it says - "We plan to announce pricing and general availability in Summer, 2016. Plans will be priced between $30/mo to $55/mo per active developer."<p>Are active developers determined from repository - or is there another way?
This sounds neat - are there plans for an on-prem version instead of EC2? We have Mirantis OpenStack running in a bubble at my organization (we are cloud-averse).