Ship Code Faster: Announcing GitHub Integration GA(blog.heroku.com)
blog.heroku.com
Ship Code Faster: Announcing GitHub Integration GA
https://blog.heroku.com/archives/2015/2/6/heroku_github_integration
14 comments
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.
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.
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.
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.
I don't understand the benefit to this as opposed to the CLI?
For me, when something is merged into master, that means that it is immediately destined for deployment.
so instead of
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).
so instead of
git co master
git merge --no-ff feature/my_feature
git push github
git push heroku
git co master
git merge --no-ff feature/my_feature
git push github
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).
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.
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.
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.
[deleted]
For 6 "performance dynos" (a whopping 30G RAM!) they ask a price of $2842/mo.
Does that include a personal assistant and foot massages?