Rollback everything - ruby-on-rails

I will be making changes to a production app soon and I would like to know how to rollback all changes to the database and code. I think with pgbackups and if needed heroku db:push and pull that will rollback the database, but what about the code? Is there a way using git that this could be done, or maybe just to copy the whole folder and copy it back in if there are errors and upload everything again?
Thanks.

For managing your code, use git tags.
Find the commit of the code currently in production and tag it.
Add a new tag to the HEAD commit you intend to push to production
If the code needs to be rolled back, you can target the older tag during your push to heroku.
You can run git log to see the history of commits. Find the commit made just prior to your last push to production. Find the hash for that commit (on the same line as the git message in the log) and tag it
git tag -a v0.1 THEHASH
Now tag your HEAD
git tag -a v0.2
Now push to heroku
git push -f heroku v0.2^{}:master
If things go bad, rollback to v.0.1
git push -f heroku v0.1^{}:master

You can do the pure git workflow, however heroku does support releases.
heroku releases will list all your releases. heroku releases:rollback v1 will create a new release containing exactly your slug as of the v1 release.
Neither this nor the git based rollback would make any changes to your data, so if there were data migrations run they'd have to be manually rolled back as well.

Related

How to make rollback commit on heroku?

I commited new version my app on heroku. But it was a bad release.
I got an error The page you were looking for doesn't exist.
I tried heroku rollback, but the error does not disappear.
I want to roll back to the previous commit on Heroku, but not touch the commit on the git.
As per heroku documentation:
The heroku rollback command does not roll back the state of any of the following:
Add-on provisioning (provisioned add-ons remain provisioned, and deprovisioned add-ons remain deprovisioned). Any add-on-related config vars do roll back.
Your app’s Heroku-hosted Git repository
Any state stored in add-ons or externally
It is your responsibility to reconcile these resources after rolling back. Consequently, you should use the heroku rollback command only when absolutely necessary.
Running on a rolled-back release should serve as a temporary fix to a bad deployment. If you are running on a rolled-back release, commit a fix to your encountered issue and push it to Heroku. As always, this updates the heroku Git remote and creates a new release.
So I do not think you can leave the git repo untouched.
Heroku always uses the github branch that you've pushed to it.
The easiest way is to fix it would be to push your github branch to it, without the errors (previous commit).
If you have pushed it to your master branch, you can watch the history of the flawed files and just copy all code that worked in your local branch, push it again to your master (or better, create a branch for it) and push this one again to heroku.

Git pull request - how to pull and update Sublime

I've made a stupid error which has messed up my database on a Rails App I'm working on. Luckily I'm on a branch and haven't committed any changes so the version on Git is in working order.
How do I now pull through the Git version and update to Sublime so I can carry on working as if nothing happened?
I've just done git pull origin master but it says up to date so I've obviously done something wrong.
I'm not keen on a db:drop so I'd rather do it this way if possible.
You can't pull again, because you already pulled every commit from your remote.
Add changes, stash them, remove the stash:
git add --all && git stash && git stash drop
This will remove every uncommited change and bring you back to the latest commit on the current branch.
git checkout 01h5y77d (find this in git, a version of the app which works)
This would print "HEAD is now at 01h5y77d..."
You don't have to commit because you did not commit the mistakes yet :)

Git last version

I was playing with my local app, trying to add devise and railsadmin which was disastrous and frustrating. I decided that it's best I just nuke everything that changed and go back to my last working git commit. But somehow my local version is different than my heroku production ver.
How do I get or pull down my heroku version to my local - or get that commit? I am trying to figure it out with docs and CLI commands but things just aren't clicking. I don't exactly understand how the versions could be different. (I made CSS changes during my last commit and it seems my local is a version behind?)
Thank you.
How are you determining "the versions are different"?
As far as I know, if "git pull heroku master" says "already up-to-date", then the last commit on your current branch and the Heroku master branch are the same.
It is possible though that you have local changes which have not been committed to your local repo. In that case, git reset --hard HEAD will throw away your local changes and go back to your last commit. This should be the exact same commit as on Heroku.
(NOTE: only do this if you really want to throw away local uncommitted changes!)

git push heroku - stop heroku pushing/uploading massive file

Having accidentally put a pretty large file which was not excluded by .gitignore in my working directory i committed my changes, pushed up to github then did a git push heroku up to production.
when i saw it was trying to push 100s of MB of data up to heroku, i killed the process.
I have since done a
git rm filename.extension
followed by
git add ., a new commit and git push. But when i get to git push heroku it insists on continuing to push this impossibly large data file.
how can i check what the offending file is, and how can i make git/heroku forget it was ever there so git push heroku can start working again...?
Thanks!
If you did a git rm large.file, the commit introducing the large.file is still in the history of your repo.
To make git forget about the commit, you'll need to remove it from your repo's history. This could be done using git rebase as described in the answers to these questions (for example):
How do you remove a specific revision in the git history?
How to remove selected commit log entries from a Git repository while keeping their changes?
After you removed the commit from the history, you could git push -f github and then git push -f heroku.
Note that git push -f could cause problems if someone fetched the state of your github repo since your last push. See chapter The Perils of Rebasing in the progit book for an explanation why.

Published using capistrano, is it possible to know which version is running using GIT? or anything?

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>

Resources