I frequently make very small releases to my production server, but often there are some milestones.
I haven't tried anything in particular, I usually just have to revert on my local machine manually and push a new update.
Is there a good way to save a particular release that I could revert to by saying something like "cap revert production -v '1.0'"?
Maybe there's some underlying git understanding I need?
Please advise!
If not, it'd sure be a nice feature...or maybe I just need to improve my development deployment knowledge!
Create git tags for your releases
git tag v1.0
git push --tags
It is then trivial to redeploy any tag. You might also create branches: a common strategy after you deployed version 1 would be to have main development happen on master, and a 1.x branch where you can backport fixes to (and then create tags 1.0.1, 1.0.2 etc. from that b
With capistrano 3 you then just need to do
cap -S branch=v1.0 deploy
Although the setting is called branch it can be a branch, a tag, a sha etc.
With capistrano 2 it's basically the same. Stick
set :branch, ENV['BRANCH'] || 'master'
in deploy.rb and we then do
cap deploy BRANCH=v1.0
Related
Ok, Using capistrano 3.2 with Rails 4.2.
Put simply I want to have each release on the live server to have an intact git repo with it. I know Cap uses git to clone the files but afik it deletes the .git folder by default. I swear I had this working before on earlier versions of Capistrano but no amount of Docs or Googling is finding the right setting. Or if I had an odd version of Cap
And before I get jumped on with "Version control on live? Never make changes to live, develop on your dev server you idiot!?"
Having an active git repo on live is invaluable if something changes out of your control, or if there is an emergency you have no choice but to monkey patch. Because now you have the change shown up by git and you can commit it, and push it back into your central repo and have it go up stream neatly. Its saved my ass before and means I don't have to copy by hand what I know has fixed the "live" issue.
Anyway, justification over. Anyone know how?
I apologies for the simple question, I think it's unlucky google fu which has left me without an answer from searching for this. Searching "Capistrano leave git on live" or other such terms are swamped with using git to deploy.
Cheer in advance.
This would be non-trivial. Capistrano uses git archive piped through tar to create the release folder. Hypothetically, you could override the task which does this, but you would probably spend more effort than it would be worth. I would highly recommend that you look at just creating a workflow where you commit a hotfix and push again. We use a prod branch at which the production deploy points, thus you could commit the change to the prod branch and cap production deploy, then merge your change back down to your development branch.
If you do choose to try and override this, look at the Capistrano source for the git tasks. It uses the Git Strategy class, so you would need to subclass and override it, then override the task to use your class. Capistrano is basically just a subclass of Rake, so look for documentation around overriding a Rake task, e.g. Overriding rails' default rake tasks.
Good luck!
I'm using capistrano to deploy a rails 3.2 app. My code is hosted on a Git server with ubuntu server. Recently i started looking in how to use more of the git features as all i was using was commit and push. Capistrano take care of taking this and deploying it in production.
The only thing unusual i did with git is the following (more people will use this git) :
git config --global user.name "syl"
git config --global user.email syl#my.mail.adress.com
Since i did that, all my new commits are ignored in the rails deployment folder by capistrano, strange thing is, if i create a clone using the command from the capistrano trace : git clone -q linuxserveruser#gitserverip:/path/of/my/master/repo/ my latest changes are here.
What happened, what can i do to put my new commit in production?
Probably you need to delete the Capistrano shared cache (and probably you moved/renamed the git repository, too.)
I hope this is an ok question for StackOverflow. If it isn't, let me know. Thanks!!
I have my first Rails app about to go production. I'm using GIT and Github for version control. And I'm using CAP to deploy to our own servers.
We have one server for Staging and one for Production.
So, lets say it's day one of production. And I'm also coding new features on my iMac. So, I'm making changes and saving to GIT, Github and staging.
But, then the users run into a small error that I need to make a quick fix on production.
Well, I've already started making major changes to the code and I don't want to put that into production.
How would I make the quick fix the users need?
Thanks for the help!
Ill assume you have a prod branch and a devel branch, and the tip of prod is what has been released to prod.
You can;
1. git stash all your current work if you havent committed it yet.
2. git checkout prod
3. Create a new branch for your hot fix, fix it, merge it back to prod and release it.
4. git checkout devel and git stash apply your stash if you need to.
5. git merge prod into your devel branch so it has the hot fix you just deployed.
If you dont have separate branches for prod and devel, now might be a good time to set them up :)
See the section 6.3 Stashing of the progit book.
http://git-scm.com/book
You may create a branch for fixies, fix a bug there, and update your application on production server with this branch. In some moment you will merge them (branches).
I am working with RoR, and have recently cloned a project via GitHub. I have a specific RVM gemset for this project, but nothing inside of it. I am not sure if I should create a new branch and then run bundle install, or vice versa. My concern is I do not want to work on the master branch, but I know I need to set up everything first run bundle install.
What is the right method to get started on this project, with out breaking the master?
GitHub is just a hosting for git repositories. Well, writing just is not giving it proper justice.
However you should learn how truly git works. I heartily recommend reading free Git Book.
In short:
git is distributed
you're working only on local working copy
if you don't tell git specifically you want a file to be tracked - it won't (surprise, surprise!).
So running bundle install will not modify what is tracked by git and - specifically - won't affect remote master. It won't modify your master until you modify some files being already tracked. I think bundle install does not. And even then to modify remote master you need to commit and push changes.
You can work on your master. It's safe.
If its someone else's project, or an open-source project, you should Fork the project on Github. Then clone the fork. This will allow you to work on the project, commit your changes locally and push them back to the forked repository.
If it is your own project, and you do indeed want to work in a branch, then clone the repo and make a branch git checkout -b my_branchname. You will then work in the branch, check your code into the branch. Eventually you will want to merge this branch into the master branch. To do this you can merge locally:
git checkout master
git merge my_branchname
Or, you can create a pull request on Github and then merge the branch into master through the Github web UI.
The bundle command, used in conjunction with RVM will just install gems locally, most likely in your home directory (~/.rvm). Gems are not packaged with the rest of the code, so you don't need to fear messing up the master repo.
I pushed code to my server using capistrano (using git also).
I then made changes on my laptop, but haven't sinced published to the server.
I want to know which git version I pushed to the server so I can rollback to that version.
Is this possible?
I know I should have used tags but kinda late for that, hoping I can figure out the version I pushed to my server, so I can rollback to that version or at least diff from that version to the current built to see what has changed since then.
Capistrano should have put a REVISION file under #{your_app}/current on the server, with the deployed commit's SHA:
So something like:
git diff `ssh your_user#your_server "cat /path/to/your/app/current/REVISION" `
should get you the appropriate diff.
yes, you can check your reflog.
git reflog
But you should be tagging when you release.
Hope this helps
git fetch
git log origin/master -1
fetch synchronizes with your server and log origin/master shows the log of your server's git repo instead of your local repo. The -1 tells it to only show the last commit. This will show the commit hash and message of the last commit on your server's repo.
If your server is listed in your remotes as something other than origin or your server is using a branch other than master, you'll have to change that. But "origin" and "master" are the defaults and are standard convention if you haven't changed it.
<subjective>
Unless you're explicitly versioning your software (like when creating a gem, for example), it's not necessary to add a tag every time you deploy your app. This would quickly become unwieldy. With git, a commit hash can be used just like a tag if it's ever needed.</subjective>