I have an application on GitHub and I am working on making an interface to easily deploy branches of the application to separate Heroku applications for various reasons. Is it possible to specify a specific Heroku application you'd like to deploy a specific branch to using a Heroku deploy button?
If you have git and heroku toolbelt installed with your application, you could easily automate it by calling in in your shell
git push [your-heroku-app-as-a-remote] [branch_name]:master
Where [your-heroku-app-as-a-remote] could be a variable containing the heroku-app you need to push, and [branch_name] a var holding the branch name you want to push.
You could always automate the fetch of all remotes/branches and also the process of creating Heroku apps on the fly. Of course, any scripting language could be used to call all these actions with ease
Related
How is a test site created with Rails 4?
I'm building a Rails 4 app. I develop locally, have a github repo, and have a live production Heroku site.
Now I want a 'test' or 'dev' site that is on the web, so all the employees working with the app can see features even before they are rolled out.
It sounds like a standard enough issue that I suspect Rails has some built in approach, making use of the "dev", "test, and "production" environment variables.
Heroku has a methodology for this --
https://devcenter.heroku.com/articles/multiple-environments
I prefer to use standard git mechanics to control the flow. On a web application we develop this really helps us. We have a reasonable sized team and what we do is:
Create a feature branch (tools like git-flow can help with keeping standards in your team)
When done we push up to our git remote, create a pull request and someone reviews the contribution. Once the changes are good they get merged into master.
As part of continuous integration (after our specs are run successfully) we have a simple Jenkins job that clean rebases into the appropriate branch and pushes to the remote.
Everyone has their own flow, but you can use your master branch as development then when you're ready merge/rebase into your other environment branches.
On your destination Rails platform (in my case Ninefold, because it's really easy), pick the branch and deploy. On Ninefold as soon as you push to your branch your app is redeployed via a Post-receive hook.
We configure up the application's environment by passing RAILS_ENV=staging / RAILS_ENV=production, and ensure you have an appropriate (environment).rb file with all the relevant settings for your environment.
I have this confusion and perhaps it may be basic question. I am planning to work on a Rails project along with a friend who stays in a different location.
We have identified Heroku as our deployment platform and Bitbucket for SCM related activities.
Both me and my friend are new to rails but we are familiar with web development in general.
I m working on a Windows box while he is on a Mac. We both have the same rails version including the gems. However, I'm not sure really sure how do we manage the source code and code integration. The reason I say this is because, when we try to commit the entire code from our systems a few platform specific rails file gets uploaded on the server, thereby rendering the deployment useless.
So my question is if I am on Windows and my friend is on Mac, whats the recommended way of working together on a single RAILS project and deploy it on a common platform to get the same desired functionality.
Yes, by using the source control management (SCM) you selected when you set up your repository.
For instance, if you use git, you would copy your repository using git clone (the command is provided via the bitbucket interface by clicking on clone), make your changes, and then git push your changes back into the repository.
When you want to code next, execute a git pull command to get the latest repo changes and then work and git push your changes back to the repo.
For examples see Bitbuckets fantastic tutorial.
As a side note, bitbucket also supports mercurial, although I haven't used it.
As far as your actual issue, each person will need to make sure the platform dependent files are excluded from your repository. If you're using git, see the git book specifically the section on .gitignore and git rm
I am working with this school project (webapp in RoR) in group of 10 and we get into this fight.
One says we should use Heroku as our web host because it does version control with git.
The other says it's cool to use Heroku as web host, but it doesn't not store old code and keep track of changes, so we should set up our own github/assembla-git.
Who is right?
Heroku uses git for deploy. So you can use it as version control too.
But I would not recommend it. When you push to heroku it's mean deploy to production. But your code can be not ready for it. Not tested yet, feature not fully implemented and etc.
You can add 2 remote for your repository.
git push origin master # github
git push heroku master
So I would recommend you use heroku as webhost and github as version control
There is nothing wrong with using Heroku as your main Git repository. I have dozens of projects that are set up this way.
Heroku is definitely not going to arbitrarily delete code or commits in your repository.
Of course, anything you push to the master branch will actually be deployed, but you are free to push other branches if you want (Heroku will simply ignore those).
The advantage of using GitHub in addition to Heroku is that you get a bunch of extra functionality on top of just the bare Git repository, such as a web-based UI and collaboration tools like pull requests, etc. Keep in mind that GitHub for private repositories is a paid service, however. There are also competitors to GitHub such as Bitbucket which offers private repositories for free for small teams.
But if you are already familiar with Git and don’t feel like you need any extra functionality on top of it, you might as well just go with Heroku. There’s something to be said for simplicity, as well.
Grails has a war command to create a Web Application Archive (WAR) file which can be deployed on any Java EE compliant application server.
Heroku apparently uses GIT and an entire repository of one's code to deploy, from what I've gleaned in the tutorials (here and here)
Can you help me understand the integration between these two aspects at a high level. Is running on Heroku just like running in your development environment, where WARs aren't used?
Thanks, Ray
Running on Heroku is running a war in a container.
The difference is that a Heroku dyno is staged via git hooks. Meaning that it builds whenever you push to the Heroku repository. The reason the plugin uses code directly is that this is much more efficient than pushing a .war pre-packaged to the platform.
What the plugin does is to facilitate what dependencies are pulled in by the git hook.
When you push your code, the git hook pulls in the dependencies of Grails and the appserver and packages it all together for you (the work the plugin does is configuration of this process).
In the end the app runs in an embedded container (or so I recon, I haven't looked at the plugin more than rudimentary since SpringOne2GX) that is packaged and staged on a special staging dyno and then deployed to run on your computing dynos.
From your applications point of view, you are running in a container and you can code your app just as you normally would (except that if you make more dynos, their sessions are not replicated, so you cant rely on sessions the same way).
Edit:
It should be mentioned, that you can push a pre packaged war to the git repo if you so want, the build system is pretty flexible, also you are not allowed to have a 'slug size' (basically the space taken by your project when its ready to run) above 100mb.
I'm trying to setup a decent development pattern with my friend. The plan is that we do independent development on our own computers, then push to the dev server for testing, and then we push from the dev server to the productive server (Heroku).
The problem is, I can't make git behave. Perhaps I just don't know enough to fundamentally understand what's happening. I've setup the repo on the dev server, but when I clone it to my personal computer, I can't "push" it back because it complains about pushing to a non-bare repo. So then I tried branching the repos, and pushing branches, but now I get a lot of fast-forward statements, and I don't think I want those either.
So my question is this. How do I setup the server so it all just "works"? The server cannot be a bare repo, it needs to have the code in it so we can test the app. We want to be able to push and pull from the repo to our own dev computers smoothly. And the server needs to be able to push to Heroku (it can do this already). This is on my own server, so I have complete access to whatever I need to get this working. (Ubuntu Server Edition 11.04).
Thanks!
The reason you can't push to a non-bare repository by default is that a non-bare repository has a checked-out working copy associated with it. When you push updates to the branch that is checked out, the working copy would become out of sync with its own repository, unless you specifically run a command to update it (which you can do using a post-receive hook). If you're aware of this and you would like to push to a non-bare repository anyway, you can set the receive.denyCurrentBranch configuration property to ignore and git will allow the pushes. For further details I refer you to a blog post I wrote some time ago (probably due for an update) which describes a similar setup that I use for my own website.
Note that instead of just development and production servers (each with their own non-bare repositories) I also have a third repository, a bare one, which I push changes to first, before sending them to dev; that way, I only ever push to the development server from one place, which helps keep things in sync.
To expound on #David Zaslavsky's comment, I would set up a bare repo to push to most of the time, then use something like git-deploy to push to your development server. You get the same semantics as pushing to Heroku, without Heroku.