I want to push my rails application from github to heroku. I have deployed my application on github and i have its url. I dont know how to deploy on heroku an application which already exists on github .
Anyone who knows please reply.Thanks
Heroku has an excellent Guide on deploying Rails 3 applications to Heroku.
You can now deploy, on Heroku, either the master branch or a feature branch from a github repo. This deployment can be done either manually or automatically (when something changes on the branch in the github repo). To make this happen, login in to Heroku, click on the app, and click the "Deploy" menu pick. Scroll down and you will see "Automatic" and "Manual" deploy choices. You can select one or both of these. A continuous integration tool -- like GoCD, Jenkins, or others -- would provide another layer of control and management for you. But this deployment method using just Heroku works well for individuals, small teams, or simple use cases.
Related
I'm moving my project to gitlab and looking at their flow and trying to get my head round CI as part of the process.
My project is in Rails and looking at lots of examples on line, people use the gitlab flow with a master branch and feature branches. They merge to master with a pull request and then deploy to staging, then either use tags to deploy to production or have a seperate production branch.
I like the idea of using tags as it suits my project.
So successfull changes in a feature branch get merged to master and deployed to staging where they are visible and then once tested its tagged and deployed to production. Happy with that.
The question (confusion) i have is.. the above is fine but assumes everthying is merged into master.
What is the strategy if you want to deploy changes somewhere which are not ready to go to master? ie you want to preview changes as they are developed
I've seen some people suggest evey developer should have a public version of thier working copy but that seems hard to manage especially with remote developers. What if two developers were working on the same feature branch?
Is it a case of having a seperate branch for this?
Or have i missed the point?
If I understand your question right, I think what you probably want to do is to have separate environment branches. So you're not only working within your master branch, you have different branches that your changes move between (and can thus be deployed wherever) before they get to the production branch.
AWS Opsworks lets you deploy an app. The deployment seems to deploy the master branch always.
How can I make it deploy a git tag?
Thanks
There is no elegant solution to this. It's a shame OpsWorks doesn't let you specify branch/tag at deployment time.
EDIT: After some digging around with OpsWorks/Chef/Ruby, you actually can deploy a specific tag relatively simply. Either of the two methods below are still valid.
You can deploy a git tag in one of the following ways:
Method 1: Specify in App settings
Before deploying, edit your App, and change the Branch/Revision value to tags/1.2.3 where 1.2.3 is the tag you want to deploy.
Save changes, then deploy your app as normal.
Remember to manually change this each time you deploy!
Method 2: Pass custom JSON on deployment action
Include the following custom JSON when you deploy your app
{"deploy": {"myapp": {"scm": {"revision": "tags/1.2.3"}}}}
where myapp is the Short name of your app and 1.2.3 is the tag you want deployed. Don't forget to include this custom JSON each time, or your deployment will default to whatever you have in your App:Branch/Revision.
Further Thoughts
For apps in build/test, you could specify develop as your Branch/Revision in App Settings, and not worry about using custom JSON each time. This will always deploy the head of develop for you.
For apps in production, you could have master as your Branch/Revision, then specify the custom JSON at deployment time. This way, if you forget to include the custom JSON, at least it will deploy the latest revision from master, which most of the time should be the same as your latest tag.
It is worth noting that if you add new instances to your layer (manually, or automatically according to your layer rules), the default behaviour would be to deploy a fresh version of your app according to the settings in App:Branch/Revision.... so actually, you'll need to be mindful of both methods depending on your exact requirements.
Have you check this? You can check Branch/Revision
section it is showing how you can deploy according to branch http://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-simple-app.html
I am actually dealing with this very same problem right now. We are moving our testing / staging environments into OpsWorks to leverage their time based instances for cost savings.
The way around this I went was a small command line ruby script to poll AWS to show me the stack list, then I can select the layer, app and the instances I want to deploy to. The script then asks for the branch name of the repo to deploy, and pushes a deploy over the AWS CLI to OpsWorks to handle.
This is all done over the AWS CLI. I will see about making this available online and post a link if it is clear with the boss.
My Rails app is hosted on Heroku. I would like to have another server for staging (i.e., showing and testing new features) before updating my main app.
I have no idea how to do this in general, and in Rails.
How should I go about it? Do I need to create entirely new app, Git repository, Heroku server etc.?
What would be the most popular Gem for this kind of job? (I hear a lot about Caspitrano, but I don't know how it helps in context of Heroku).
Thank you very much for your help.
Heroku documentation is covered this case. You just need create another branch for staging.
Check it https://devcenter.heroku.com/articles/multiple-environments
I currently have an app that is live. I want to add a bunch of new functionality to it, but don't want to upload it via heroku until it is completely finished. The new functionality stuff is quite extensive so it will be done via multiple git branches.
My question is, how do I continue to build out the app while keeping the existing one running and being able to fix minor things here and there on the live site without having the WIP stuff shown?
Thanks.
Check out
http://nvie.com/posts/a-successful-git-branching-model/
Your issue is resolved by the hot fixes branch. "Merge"/copy production to the hot fix branch. Test the change. When the testing passes, merge the change into production and merge the change into development.
You should deploy another copy of your application that will be your testing/staging environment. Deploy to it while you develop. After you're done developing, merge everything to master and deploy to the production env.
Also, read the link that #MarlinPierce posted. It changed my life :)
What is a good deployment strategy to use with Git + Heroku (Ruby on Rails)?
Currently, the way I work with my origin Git repository: All features (or 'stories') are first checked out as branches, then get merged with master and pushed to origin.
Anything pushed to origin/master triggers a script that pulls the new rails code to the staging area (simple rails webserver).
When the time comes for me to push a new production version to Heroku, should I create a new branch (called something like production_version_121), and push that somehow to Heroku?
Ideally, I'd like to pick and choose which features from previous development versions I should include into the production branch... test it, and push to Heroku.
For example, I may not want all the latest code to get pushed to production. I might want to feature "a" that I had worked on and feature "c" both merged into production somehow, without including experimental feature "b" which needs more debugging.
N.B. I'm going to try avoiding Capistrano at first and get something working manually for now.
Any thoughts? Best practices?
In the Gemcutter project we simply have a production branch. Any changes that we want to see on the production site get merged into that branch, and then deployed with:
git push heroku production:master
The staging branch serves a similar purpose for the staging site (also on Heroku)
Ever since I read Vincent Driessen's A successful Git branching model, I have been hooked. My entire company (8 of us) have now standardized on this model and a few other places I've consulted with have also started using it as well.
Most everyone I've shown it to says they were doing something similar already and found it very easy to adapt.
In a nutshell, you have 2 branches that are permanent (master and develop). Most of the time you'll just be making branches off of develop and merging them back into develop. Things get a little more complex when you get into doing production releases and hotfixes, but after reading the post a couple of times, it becomes engrained.
There's even a command line tool called git-flow to help you out.
There are a variety of ways to go about this, and it really depends on your preference.
I'll give you one possible strategy off the top of my head: Given you already have an automated staging setup that uses master, I would suggest creating a 'production' branch. When you want to promote a fix/feature to production, you would just merge the topic branch into your 'production' branch.
git checkout production
git pull . my-topic-branch
(resolve any conflicts)
When you are ready to actually push that code to your production server, you should tag the branch using a unique name (probably with a timestamp). Then you simply push the production branch to Heroku.
git checkout production
git tag release-200910201249
I'd suggest creating a script or git alias to automate the tagging for timestamps, since using a consistent naming scheme is important. I use something like this:
git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`'
That allows me to do just type git dtag when I want to tag a release with a timestamp.
You can view you tags using git tag and view them using git show release-1234. For more information on tags, run git help tag. You may also find this Github guide on tagging helpful. I'd also recommend reading up other people's workflows (here's a nice writeup) and pick and choose what works for you.