Ruby deploys temporarily disabled
status.heroku.com
Ruby deploys temporarily disabled
1–10 of 98 posts
Re: Ruby deploys temporarily disabled
#2Good to see them being proactive about it. Wonder how quickly they will be able to determine that Ruby/Gems are safe to deploy again.
Re: Ruby deploys temporarily disabled
#3I always assumed that Heroku would have an internal proxy for gems. Seems like 80% of users would probably be fetching the same gems that another user might have just fetched. Perhaps something like this could be versioned or snapshotted so that in the event of something like this, you could roll your cache back to that snapshot and let people deploy who had gems in that cache.
I'm just thinking out loud.
Re: Ruby deploys temporarily disabled
#4I always assumed that Heroku would have an internal proxy for gems. Seems like 80% of users would probably be fetching the same gems that another user might have just fetched. Perhaps something like this could be versioned or snapshotted so that in the event of something like this, you could roll your cache back to that snapshot and let people deploy who had gems in that cache. I'm just thinking out loud.
Which snapshot do you roll back to?
Re: Ruby deploys temporarily disabled
#5The DAY I manage to convince the big wigs where I work that we should switch from a typical shared environment to Heroku, this happens.
Talk about luck. :(
Hopefully I can spin this and not leave a bad taste in their mouths. We (engineers) understand what's happening, management doesn't and they don't give a shit.
Re: Ruby deploys temporarily disabled
#6This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI.
Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have previously needed to externally fetch.
Re: Ruby deploys temporarily disabled
#7The DAY I manage to convince the big wigs where I work that we should switch from a typical shared environment to Heroku, this happens. Talk about luck. :( Hopefully I can spin this and not leave a bad taste in their mouths. We (engineers) understand what's happening, management doesn't and they don't give a shit.
Safe by default. That's your angle.
It's additional effort to deploy dangerous code.
Re: Ruby deploys temporarily disabled
#8The DAY I manage to convince the big wigs where I work that we should switch from a typical shared environment to Heroku, this happens. Talk about luck. :( Hopefully I can spin this and not leave a bad taste in their mouths. We (engineers) understand what's happening, management doesn't and they don't give a shit.
they give you a straight forward workaround to still deploy. They just make you set a value explicitly so they know you are aware of the risk.
Good to know someone is watching your back :)
Re: Ruby deploys temporarily disabled
#9This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI. Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have pre…
They still allow you to deploy you just have to explicitly set a variable in the deploy command so they know you are aware whats going on
Re: Ruby deploys temporarily disabled
#10This should also be a reminder to everyone that you shouldn't be reliant on a single point of failure for your deploys. It's something that we in the Python community have already encountered (and hopefully learned from) due to the historical unreliability of our equivalent package repo, PyPI. Have an internal repo that's accessible by your deploy servers, which in turn locally caches anything that you might have pre…
They still allow you to deploy you just have to explicitly set a variable in the deploy command so they know you are aware whats going on
The point was unless you also previously cached all your gems somewhere you'd have to deploy using potentially compromised gems from rubygems.