Recently, I want to migrate my side project into another domain. This project is currently hosted on Heroku platform. I really like the concept of push-to-deploy that Heroku good at. It frees me from server-management thingy. And, I feel so geeky whenever I use git from command line, hahaha. Ok, let me explain the state of the app.
Application Environment in Heroku Platform
The app has two different environment: staging and production. I think the names are self explanatory, otherwise you do not have enough experience in developing software. Each environment will point to different branch in developer local machine. The staging environment itself is pointing to development branch. At least in my local machine. My first local machine that I use originally for this project. The production environment is pointing to master branch in local repo. I know it sounds confusing. Because it really is. And that confusion slapped my face hardly when I try to rename my app in order to migrate the domain.
So, each application in Heroku will has its own repository. In my case, staging app will have repo name with -staging in it. The production app simply the name itself, without prefix or suffix. At first, I naievely clone each app in different local repo, which make me even confuse and question my existence. So if I have two repos, I need to work in two different place? Hell no. That’s the wrong way, Seto.
The Right Way (Really?)
The right way, it turns out, is to only clone the staging app. Why? Because it contains all the commit before merging them to the production branch: master local branch. I mean remote production branch. I mean, what??? Anyway, just continue the reading.
After you clone the staging repo, automatically you’ll get heroku remote. Oh no, that’s when you use heroku command heroku git:clone -a [app name]. Otherwise, I think you’ll get origin as remote name. Check it.
1 2 3 | |
You want to make naming remotes and branches reflect to the environment and how you’ll work. So, change the remote name into staging, the same name as the application environment it listed as the git repository.
1
| |
And the next step is to add production app as production remote with the magic of git. Now I’m arguing my opinion to name the remote the sama with the app’s environment. So production remote is production app and staging remote is staging app? mikir
1 2 3 4 5 6 | |
And then, you need to fetch each remote like so:
1 2 3 4 5 6 7 | |
Now is a bit tricky but should be understandable. Make sure local master branch track production/master and local staging branch tracks staging/master.
1 2 3 4 5 6 | |
`bundle install` And The PostgreSQL Thingy
After you finish with the git stuff, you need to install the dependency. Use bundle.
1
| |
And will most likely face this issue after running that command.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | |
This is because the app is using PostgreSQL, and you don’t have the database yet. You usually use Postgress.app for the installation. Or you can use other PostgreSQL distribution (is this the term?). Frankly speaking, it because it’s the default database for Ruby stack on Heroku that we use PostgreSQL. But I like it. So doesn’t really matter to me.
You need to install postgresql via Homebrew.
1
| |
You might need to change password and username for your local database, since you committed them on your other machine.
Run The App Locally
If you’re lucky (and you’re always), you will be able to run the app locally with herokucommand:
1
| |
Easy breezy lemon squeezy, eller hur? Hejdå!