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
Related
I'm working in a rails project which uses SVN as central repository, but i'm working (locally) with git-svn, and I want to add a remote where i will only push master for testing purposes (i will push to Heroku).
I've read this from chapter 9.1 of Pro Git (my emphasis):
Don’t rewrite your history and try to push again, and don’t push to a
parallel Git repository to collaborate with fellow Git developers at
the same time. Subversion can have only a single linear history, and
confusing it is very easy. If you’re working with a team, and some are
using SVN and others are using Git, make sure everyone is using the
SVN server to collaborate — doing so will make your life easier.
I won't be collaborating with other Git developers (everyone else is using SVN), but before setting it up, i just want to be sure if there are any associated risks in doing this, and if so, what should/could i do about it.
If it's only for pushing to a repo so that you can then checkout/build/deploy, it won't hurt. That warning you noted is stated there so that you don't start moving around doing crazy things on the repo where you work with git-svn to relate to other developers also using git-svn (plus other restrictions) because of the way that revisions are kept on git-svn.
I am using jenkins to continuously build the website front-end code from github repository, package it up into the tar archive and post the it to the S3 bucket. The Jenkins build creates files named like this FrontEnd-122.tgz where 122 is the build number.
I am using the following recipe to deploy the app onto the server:
deploy_version = node['my-app']['build-number']
deploy_from = "http://mybucket.com/FrontEnd-#{deploy_version}.tgz"
tar_extract "#{deploy_from}" do
target_dir '/usr/local/site/FrontEnd'
creates '/usr/local/site/FrontEnd/index.php'
tar_flags [ '--strip-components 1' ]
end
This all works great, however I have to manually update the node attribute my-app/build-number. Which is fine for QA and production deployments.
What I would like to do is to have a snapshot deployment VM, where I the latest code gets deployed, for further testing with selenium and friends. However, to do that I need to
have a way for the above cookbook to figure out what is the latest build number is and deploy from there. Do you have any suggestions?
Tricky one because you need a mechanism for chef to determine the latest revision stored in S3.
Presumably you store the code in a revision control system like subversion or git? Would it be feasible to use the chef deploy resource instead? Let chef pull the website code from your trunk or master branch, for testing purposes.
Another option would be to use a binary repository manager that understands the concept of "Snapshots". Take a look at products like Nexus, Artifactory and Archiva. You could then use S3 for both backup and a distribution area for approved and released copies of your site.
So, I used the dumb way to solve this issue. Besides putting the versioned archive to the S3 bucket. I also push the same archive using the name like 'FrontEnd-Latest'. Also I modified the cookbooks to use a version parameter. The staging server has version parameter set to 'Latest' and the production server has the parameter set to whatever version is considered to be stable.
I'm beginner on rails, heroku and git, but I've done all installation stuffs.
I created two projects on heroku.com, but I don't know how to change them from my PC (the way I looked from help doesn't work such as "$ git push heroku master").
So, how can I edit one of my herokuapp in different computers?
As I understand, I need git commands to bound my projects on PC to herokuapp, and commands to update projects from heroku to my PC (mostly 2 different Win 7 and sometimes iMac). Am I right? Does anybody can tell me how it's works?
Thank you
If you haven't ever used a version control system before you might be in for a steep learning curve.
Git allows you to manage source revision across distributed repositories. In your case, it might make sense to set up a GitHub account and create a git repository there, then use that as your master repository. You use git to pull code from the master repository to your local machine, where you make your changes. You commit your changes to your local repository and then push these changes to the master repository.
On your heroku account you then git pull from the master repository to retrieve the changes you made.
This brushes over a lot of detail that you need to know. I suggest you start googling git tutorials and read up about how git works and how it's intended to be used.
If you are totally new to git and heroku i would suggest you to go through this
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.
I am developing some school grading software and decided to use Github to host the project. After building some code on my Ubuntu box I pushed it to Github and then cloned it down to my MacBook Pro. After editing the code on the MBP I pushed it back to Github. The next morning I tried to update my repo on the Ubuntu box with a git pull and it gave me all kinds of trouble.
Whats the best way to work in this situation? I don't want to fork my own repo and I don't really want to send myself emails or pull requests. Why can't I just treat Github like a master and push/pull from it onto all of my personal repos on different computers?
I'll assume your problem was that the machine on which you first created the repo crapped out when you tried to issue the git pull command.
When you clone an existing git repository (like you did on your 2nd machine, the MacBook Pro), you're automatically set up to so your git pull commands will automatically merge the remote with your local changes.
However, when you initially create a repo and then share it on a remote repository, you have to issue a few commands to make things as automated as a on cloned repo.
# GitHub gives you that instruction, you've already done that
# git remote add origin git#github.com:user_name/repo_name.git
# GitHub doesn't specify the following instructions
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
These last few instructions configure git so future git pull's from this repo will merge all remote changes automatically.
The following is a bit of shameless self-promotion. If you use Ruby, I have created a Ruby-based tool that lets you deal with all these kinds of things with git remote branches. The tool is called, unsurprisingly, git_remote_branch :-)
If you don't use Ruby, my tool is probably gonna be too much of a hassle to install. What you can do is look at an old post on my blog, where most of the stuff grb can do for you was explicitly shown. Whip out your git notes file :-)
You can also add multiple SSH public keys.