Introducing Heroku Fork(blog.heroku.com)
blog.heroku.com
Introducing Heroku Fork
https://blog.heroku.com/archives/2013/6/27/heroku-fork
9 comments
Fuck you, Heroku!
I made something similar to this for Diaspora: https://bitbucket.org/tubbo/replicator
Guess it's not needed anymore! :) Incidentally, if you for some reason want to bake this functionality into an existing gem, it may be easier to use Replicator's library than the Heroku API, since I had to read their source to understand how it all worked. That is, if for some reason you don't want to drop down to the command line and run `heroku fork` from Ruby.
I made something similar to this for Diaspora: https://bitbucket.org/tubbo/replicator
Guess it's not needed anymore! :) Incidentally, if you for some reason want to bake this functionality into an existing gem, it may be easier to use Replicator's library than the Heroku API, since I had to read their source to understand how it all worked. That is, if for some reason you don't want to drop down to the command line and run `heroku fork` from Ruby.
Hopefully the new version of our API would make that kind of thing easier in the future since it's very thoroughly documented: https://devcenter.heroku.com/articles/platform-api-reference
I assume you've being downvoted by people who saw "fuck you" and stopped reading before getting to the ":)"
'Fork you' ?
Suddenly setting up a staging environment doesn't suck.
Looks great! Unfortunately after the RapGenius fiasco, I don't trust Heroku as a service provider.
Every company makes mistakes. Who hasn't fallen behind on site copy? Granted their responsibility to keep documentation up to date is much greater than most of ours but I'd like to think (and I believe) they were not willfully deceiving their entire Rails customer base. I am still a fan.
But they didn't correct the problem -- they should have refunded at least some of their costs.
Are you sure they didn't?
Refunds could easily have been something evaluated on a 1-by-1 basis, quietly, to avoid creating a stampede of requests even by those negligibly affected.
Notably, despite all the public feuding, RapGenius today still appears to be served by Heroku.
Refunds could easily have been something evaluated on a 1-by-1 basis, quietly, to avoid creating a stampede of requests even by those negligibly affected.
Notably, despite all the public feuding, RapGenius today still appears to be served by Heroku.
Heroku is amazing, hands down. It's a shame you don't give them credit for all they've done for web app developers.
trashes old automation scripts
Finally it came out of beta... Probably one of the best features for a sane development workflow.
Finally it came out of beta... Probably one of the best features for a sane development workflow.
Is it officially out of beta? I tried it a couple weeks ago and found that it didn't successfully re-provision several of my add-ons.
Add-on provisioning can fail (independent of fork). In that case fork still continues the rest of the process.
If you find it's always the same addon(s), please let us know.
If you find it's always the same addon(s), please let us know.
Imagine how easy-to-use AWS would be if AMZ had anywhere close to the level of focus on usability that Heroku consistently demonstrates.
And imagine how limited it's capabilities would be!
I'm not suggesting dumbing-down their product in any way. I'm talking about a usable, well-designed CLI and web console.
They've made quite a few incremental improvements over the years, but it's still mediocre at best.
They've made quite a few incremental improvements over the years, but it's still mediocre at best.
Copies the source app's Heroku Postgres data, if present.
Won't that take a prohibitively long time for large apps?
Won't that take a prohibitively long time for large apps?
At least they give fair warning..
https://github.com/heroku/heroku/blob/master/lib/heroku/comm...
https://github.com/heroku/heroku/blob/master/lib/heroku/comm...
I have 7GB of data sitting in one of their Postgres instances right now. It only takes a couple minutes to backup and restore to a new db, so I guess it depends on how you'd define "prohibitively long."
It's remarkably fast. The network transfer is AWS-to-AWS if you do it right, so the only time is creating the backup and populating the new DB. It takes almost no time for a ~5GB database I'm using.
Now if only Github added Heroku integration, so you could fork apps AND code straight from the repo.
There are quite a few companies playing in that space right now. Personally, if that is your challenge, I wonder what you are even doing making products. Let me write the deployment script for you:
heroku create
git push heroku masterYou can already hook up this really sweet Github -> Travis CI -> Heroku bridge. Every push runs your tests, if they pass, deploy.
It'd be neat to modify this so that pull requests spun up an app you could play with. Travis provides an environment variable that lets you know if you're testing a pull request, hmmm...
It'd be neat to modify this so that pull requests spun up an app you could play with. Travis provides an environment variable that lets you know if you're testing a pull request, hmmm...
Is this really HN worthy? It must be a pretty easy feature to implement with their slug/container workflow. With technologies such as Docker pushing them, Heroku ought to find a way to lower their prices. This at least adds value, but no magic here.
You could ask the same thing of 90% of the stuff here
If you wanted to build something like this, you could do so without any involvement from us by just using the (newly-documented) Heroku Platform API: https://devcenter.heroku.com/articles/platform-api-reference