Ship Code Faster: Announcing GitHub Integration GA | Hacker News Reader

Ship Code Faster: Announcing GitHub Integration GA

blog.heroku.com

50 pointsjoeyespo13 comments

Am I missing something or has Heroku pricing gone from insane to complete batshit since I last looked?

For 6 "performance dynos" (a whopping 30G RAM!) they ask a price of $2842/mo.

Does that include a personal assistant and foot massages?

At that price it only makes sense if you have something to automatically and agressively resize your app. Something like scale up to 6 dynos for a couple hours after you hit the front page on reddit, then scale back down.

Or adhoc or scheduler jobs (similar to cron jobs). Mine run twice per day but only consume 25.128h per month because the breakdown is per minute.

scale up to 6 dynos for a couple hours after you hit the front page on reddit

Scale "up" to 6 dynos?

Even if 6 of these were equivalent to 6 of the fastest EC2 instances (which is very unlikely), that's hardly the kind of hardware to survive a reddit'ing, if you serve any dynamic content at all.

> If an issue is encountered during a Heroku deployment, be it manual or automatic, you can always rollback to the last known good release from either the CLI or in Dashboard.

How do you know if the build failed other than looking at the dashboard?

When deploying through the CLI, I can check the exit status of the command so my CI can take care of it and notify me of any issue.

If the build fails, it won't be deployed and no rollback will be necessary.

With automatic deployments, if you have metrics or monitoring and discover a problem with a deployment, you can use rollback to revert. Just like you would have done with a release created by git-pushing to Heroku.

But how can I be notified of the fail?

When I deploy I don't look at the dashboard, I go back to business until my CI tell me deployment succeeded or failed.

>But how can I be notified of the fail?

In lots of deployments you can set to receive an email or even SMS for one...

I don't understand the benefit to this as opposed to the CLI?

Disclaimer: I don't use the git CLI and I've deployed maybe 3 apps to Heroku, all just playing around with it.

Isn't this so that someone can just keep Github up to date and they don't need to use the CLI and do `heroku push` or whatever every time there is an update?

We use Microsoft Azure for some public sites, and there is both Github and BitBucket integration where you can automatically deploy updates to certain branches (e.g. `master` or `develop`) to the site.

You could use something like "git push heroku master" before, but with this you dont need to setup a separate remote when using github+heroku, you can simply just push to github, that means the code that you see on github is the same as the one running on heroku, that wasn't always the case before.

For me, when something is merged into master, that means that it is immediately destined for deployment.

so instead of

    git co master
    git merge --no-ff feature/my_feature
    git push github
    git push heroku

Just becomes

    git co master
    git merge --no-ff feature/my_feature
    git push github

Just saving a step. And also saving the confusion that happens when something is in master and not deployed because someone got distracted.

Also, you could deploy to heroku as the result of merging a pull request through the github web-ui (if you're into that kind of thing).

I use atmos/heaven for a similar functionality. It's nice because it ensures that the master branch on Github has gone through out automated tests and that whoever is deploying is deploying exactly the code from Github and not some strange variant locally.

Reply on news.ycombinator.com