kathyonu/Rails-app-steps-in-production-on-heroku.md

## Rails-app-steps-in-production-on-heroku.md

      
    Raw
  

              Rails-app-steps-in-production-on-heroku.md
            
          
    Preparation

Deploying Rails Applications with the Puma Web Server

Deploying with Git

Pushing Up Your App to Heroku

Setting Up Heroku Environment Config

Setting Up the Database

Setting Up the DNS

Setting Up the Domain Name Forwarding

Setting Up the SSL Certificate

Setting Up Mandrill and MailChimp

Setting Up Stripe

Setting Up Stellar

BE AWARE AS OF 20160206 THIS GIST IS NOT YET READY FOR PRIME TIME.

I believe the commands are accurate up to Setting the Domain Name Forwarding.

I am still assembling and verifying commands, so read with care, and

please forgive duplications or such still here.
The visitmeet.com Custom Domain Name will be created and used in this gist.

We are using by quoting below, snippets of Heroku Definitions and Instructions.

You can begin using Heroku for Free.

We are using Ruby on Heroku.
The goal of this Gist is to take your app from development and staging,

to in production, safe and secure on Heroku, with attendant services set up and working.

Ruby-2.3.0    : Instructions are designed for use with Ruby 2.3 version
Rails-4.2.5.1 : To bring your app up to date on both :
Rails-applications-health-codes.md

Rails 5.0.x   : If you are preparing for Rails 5, this is good news :
Rails-5.0.beta2.
Also see : Getting Started with Rails 5.x on Heroku.
PRESUMPTIONS :

You have Homebrew and RVM set up and working.

You have your Heroku account, and the Heroku Toolbelt installed.

You have your Github.com account, and are familiar with your github respository,

your app's remotes, etc. We will be going over some of the beginning / setup steps,

and moreso when we get to the point of setting up the Heroku --staging and --production remotes.

Running heroku help displays a usage summary:
heroku help


Running heroku apps shows all our apps on Heroku:
heroku apps


App Commands :
App commands are typically executed from within an app’s local git working copy.

The app name is automatically detected by scanning the git remotes for the current

working copy, so you don’t have to specify which app to operate on explicitly.

For example, the heroku apps:info command can be executed without any arguments

inside the working copy, change example to your app's name:


cd example
heroku apps:info

  
=== example
Git Repo:       git@heroku.com:example.git
Owner:          you@example.org
Repo size:      960k
Slug size:      512k
Stack:          cedar-14
Web URL:        http://example.heroku.com/
  

If you have multiple heroku remotes or want to execute an app command outside

of a local working copy, you can specify an explicit app name as follows:


heroku apps:info --app example

For clarity along the way, both types of this usage will show throughout this Gist.

Do you know your Heroku version on your machine ?

If you do not, and you want to check, use this command in your Terminal:

heroku --version

You should see heroku-toolbelt/x.y.z.


At any time you can run through the steps below to keep your app humming.

Preparation


If you are using systems other than Homebrew and RVM ..

I can imagine you can easily adapt your usages from the following.

You have already put your app in perfect health with: Rails-applications-health-codes.md.

These commands will now look familiar ..

Open new Terminal:

rvm get stable

brew update

brew doctor

pwd

cd your_application_name

rails -v

ruby -v

rvm gemset list

As needed to be current, make appropriate changes here:

open -e Gemfile

open -e .ruby-gemset

open -e .ruby-version

rvm gemset use Rails4.2_app_name --create --default

rvm gemset use Rails4.2_app_name

Before you push to production, check your Gemfile.lock for vulnerabilites:

Is It Vulnerable ?

Explanations :

#rvm get stable updates your rvm:

rvm get stable

#brew update will update your Homebrew (takes a while):

brew update

#brew doctor will tell you all is well with your Homebrew (takes a while):

brew doctor

A good first step is to make sure you are in your working directory ..

#pwd will show you what directory you are in:

pwd

Change into your working directory:

cd your-application-name

Check your Ruby version. Expect version to be 2.3.0 or later:

ruby -v

Check your Rails version.  Expect version to be 4.2.5.1 or later:

rails -v

#rvm gemset list allows you to see which gemset is being used.

Because you set the --default switch when creating the gemset,

you should now be using that gemset.

Otherwise, we look for and change to the gemset you want application to use:

rvm gemset list

Choose your correct gemset for your app, if you have more than one.

your-application-gemset-name is the one you want, or ..

let us presume this is your first gemset ..

we will create a good name for it : "Rails4.2_app_name"

Yes, change the _app_name to your app's name for easy reference.

For the first time use, we will add the create and default switches:

rvm gemset use Rails4.2_app_name --create --default

Now run the prior command again, and you will see the gemset being used:

rvm gemset list

You just created and are now using the application's gemset.

The --default switch will cause this gemset to be used when

you first enter the app directory. At this point, I personally

like to close that terminal window and open a new one, and watch

the rvm magic show itself as it recognizes the new gemset,

if this is the first time you set it.
If you ever change gemsets, the use command is the way back.

However, at this point, when you change directory into this app,

the .ruby-gemset file will be used to set the correct gemset:

rvm gemset use Rails4.2_app_name

You can use the command to change gemsets and change back:

rvm gemset use Rails4.2_app_name

rvm gemset use Rails5_app_name_stage

Your app is now ready to go.

Fasten your developer's belt, here we go.

INSTRUCTIONS ::

Study well : Deploying Rails Applications with the Puma Web Server


"Heroku recommends using the Puma web server instead of Unicorn.

If you are using Unicorn, your application is not protected against a slow client attack."


Heroku Note:

"Always test your new deployments in a staging environment before you deploy to your production application.

See Managing Multiple Environments for an App for more info."

I suggest giving full attention to the 'Setting staging behavior section.'
We will be using the Heroku information for multiple environments of production and staging, later.

Deploying with Git

Verify you are in your app's directory if need be:

pwd
Now open your application's .gitignore file:

open -e .gitignore
It is critical that your .gitignore file ignores certain files.

Make sure yours ignores stripe and other logs.

We use the following .gitignore file:
  
#----------------------------------------------------------------------------
# Ignore these files when commiting to a git repository.
#
# See https://help.github.com/articles/ignoring-files for more about ignoring files.
#
# The original version of this file we began using long ago is found here:
# https://github.com/RailsApps/rails-composer/blob/master/files/gitignore.txt
#
# Corrections? Improvements? Create a GitHub issue:
# http://github.com/RailsApps/rails-composer/issues
#
# This file has additions beyond the above reference.
#----------------------------------------------------------------------------

# bundler state
/.bundle
/vendor/bundle/
/vendor/ruby/

# minimal Rails specific artifacts
db/*.sqlite3
/db/*.sqlite3-journal
/log/*
/log/*.log
/tmp/*

# various artifacts
**.war
*.rbc
*.sassc
.rspec
.redcar/
.sass-cache
/config/application.yml
/config/config.yml
/config/database.yml
/config/local_env.yml
# If you put the config/secrets.yml file into .gitignore,
# you won’t be able to deploy to Heroku, therefore it is NOT commented out.
/config/secrets.yml
/coverage.data
/coverage/
/db/*.javadb/
/db/*.sqlite3
/doc/api/
/doc/app/
/doc/features.html
/doc/specs.html
/instructions/*
/lib/membership-data-entry/*
/public/cache
/public/stylesheets/compiled
/public/system/*
/spec/tmp/*
/cache
/capybara*
/capybara-*.html
/gems
/specifications
rerun.txt
pickle-email-*.html

# If you find yourself ignoring temporary files generated by your text editor
# or operating system, you probably want to add a global ignore instead:
#   git config --global core.excludesfile ~/.gitignore_global
#
# Here are some files you may want to ignore globally:

# scm revert files
**.orig

# Mac finder artifacts
.DS_Store

# Netbeans project directory
/nbproject/

# RubyMine project files
.idea

# Textmate project files
/*.tmproj

# vim artifacts
**.swp

# Environment files that may contain sensitive data
.env
.powenv

# tilde files are usually backup files from a text editor
*~

# StripeMock server
/stripe-mock-server.log
/stripe-mock-server.pid
  

Save and close your file after any changes.

Now run:

git status

You will see the file changed is noticed by git.
To add the file to the git index in your .git directory.

To add all modified files use:

git add .

or to add files one by one, use their name,

in this case it is a dot file:

git add .gitignore
Git will tell you what branch you are on, and changes to be committed.

Make your first commit with the commit command, the -m switch means message:

git commit -m 'my commit message'

or ..

git commit -m 'updated .gitignore file'
Per the Heroku Deployment material, "This is a local repository,

now residing inside the .git directory. Nothing has been sent anywhere yet;

you’ll need to create a remote and do a push to deploy your code to Heroku."
You can prove this to yourself by running this command and you will see

in the contents of your application's directory your .git directory:

ls -aux

WARNING: DO NOT MAKE ANY CHANGES OF ANY KIND, unless you are a pro, with

the following commands. Consider this a serious case of look but do not touch.


You can further prove this by changing into this directory:

cd ./.git

or if you prefer:

cd .git

it is the same result.


Run this command in the .git directory you are now sitting in:

ls -aux

You will be seeing the contents of your .git directory.

I repeat, you may look but DO NOT CHANGE ANYTHING HERE until you are a pro.

GIT REMOTE :

You can see your current git remote addresses with this command:
git remote

git remote -v

git remote --verbose
By running all three commands, you will see the differences. -v is short for --verbose.

Another command available is:

cat .git/config
One more command, giving you all info on your original remote called origin.

git remote show origin
If this fails to show any git remote address, we will now add them.

Note regarding git remote add and git remote set commands:

The git remote add WAS used to add remote addresses.

The git remote set  IS used to add remote addresses.

The git remote set-url is used to change remote addresses.

Before you can set a Heroku remote address you need to create your app on Heroku.
Creating a named app on Heroku:

Template:

heroku create example
Our usage:

heroku create visitmeet
Heroku Create Note:

"The command’s output shows that the app will be available at

http://example.herokuapp.com. The second URL, git@heroku.com:example.git, is the

remote git repository URL; by default, the heroku create command automatically

adds a git remote named “heroku” pointing at this URL."

BEFORE YOU PUSH YOUR APP TO HEROKU:

Heroku recommends using the HTTPS type of transfer.

Prove this to yourself by visiting any repository and look

above the app's directory, you will see the HTTPS address to

copy and use to clone the respository. Click on it, and the

Modal window will show Heroku instructions on both HTTPS and SSH.


Template for adding remote name and address using SSH:


Example of adding an SSH style origin remote, which we will NOT be using:

This will give the remote a name of origin and an address with username and repository name.

git remote set origin git@github.com:USERNAME/OTHERREPOSITORY.git


Example of adding HTTPS remote, which we will be using:

git remote set origin https://github.com/yourgithubusername/repositoryname.git

Our git remote named origin is created when we clone the repository.

You can see it now, with this command:

git remote -v
We are going to connect our new clone on our machine with our upstream remote,

the source of our fork. We forked, we cloned, we now set the remote upstream address.

In our case, our kathyonu/visitmeet fork is forked from the first master at:

https://github.com/bishisht/visitmeet
Template:

git remote set upstream https://github.com/forkcreator/repositoryname.git
Our usage on our fork, yours will be your name and app name:

git remote set upstream https://github.com/bishisht/visitmeet.git
You can prove to yourself the remote upstream has been set with this command:

git remote -v
Our usage:

git remote set origin https://github.com/kathyonu/visitmeet

https://github.com/kathyonu/visitmeet.git

We just visitied the newly named github repository named as:

https://github.com/bishisht/visitmeet


We forked it into our respositories folder and now that we have our fork,

I look on my new fork page for the HTTPS address to clone.


Here, we will be cloning our fork of the visitmeet.com respository,

changing into the newly created directory, and upon receiving notice

from RVM in the Terminal, instructing us to run the third command:

git clone https://github.com/kathyonu/visitmeet.git

cd ./visitmeet

rvm install ruby-2.3.0

a Ruby install can take a while, so you can watch it happen in the Terminal,

or go enjoy life in the nowments somehow someway away from the screen for a few.

The install will finish, and you will see it all when you return.

Now check your git remote addresses with the verbose switch, -v

git remote -v
You should see one address at this time showing like this:

origin https://github.com/yourgithubname/visitmeet (fetch)

origin https://github.com/yourgithubname/visitmeet (push)
Next step is to synchronize your fork's master branch with what is called,

your upstream, the place you forked from. You will want to add

the upstream address to your app's git remote addresses.
Template using HTTPS address:

git remote add upstream https://github.com/yourgithubusername/repositoryname.git
Our usage:

git remote add upstream https://github.com/bishisht/visitmeet.git
To verify the remote has been added:

git remote -v

A FINE POINT we won't be using, though it is good to know how to CHANGE any of

your remote addresses, use the set-url command. I don't think you find much need

for this but, I found I needed to understand the difference between

the git remote add remotename repoaddress and

the git remote set-url remotename repoaddress commands, for my own learnings in this.

If you create a remote named bobscode:

git remote add bobscode https://github.com/bobsgithubusername/bobsfirstrepositoryname.git

and you want to change to another repository address, this command will do it:

git remote set-url bobscode https://github.com/bobsgithubusername/bobsfirstrepositoryname.git
Template:

git remote set-url bobscode https://github.com/bobsgithubusername/bobssecondrepositoryname.git
DONE: verified this set-url usage one more time.

DONE: set-url is used to change a remote address.

DONE: if you use set-url to attempt to add a new remote,

you will receive an error: fatal: No such remote 'bobscode'

Template for adding upstream remote to your fork's source:

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git


Example, do not use :

git remote add upstream https://github.com/noonesrealname/anothersrespository.git

Our real example usage to add the upstream remote name and its address:

git remote add upstream https://github.com/bishisht/visitmeet.git

Please do read the next paragraph and the link's material before you run the command.

By setting your upstream remote address, you are able to keep your

origin master in sync with the upstream master, thus keeping your fork in sync

with where it came from, master to master. Never develop any new feature or fix in

the master branch. Always work in a new feature branch. The purpose of a fork is to

contribute improvements as you can. This will make more sense as we continue with

these instructions.

Our usage: if you forked the original visitmeet repository:

git remote add upstream https://github.com/bishisht/visitmeet.git
After running that command, you can see the new remote has been added with:

git remote -v

This sidebar note has not been verified as yet, instructions may not be accurate.

The git remote add command can also be used to enable you to pull any named file

or directory from any github repository. An example:

git remote add bobscode https://github.com/bobsgithubname/bobsrepositoryname.git

This will allow you to run git fetch bobscode and this command can be added to

allowing you to pull any single directory or file or commit number.


TODO: with each todo below, set the remote and show the commands and results.

TODO: find example of pulling one commit on another's repository into this app

TODO: find example of pulling one file on another's repository into this app

TODO: transfer all the fork data and commands and such to a Fork article on our site.

REASONS : To improve the focus of this Gist. as forking is far beyond the original intention.

To remove a remote address:

git remote rm remotename
TODO: commands to follow ? is this section done ?
Pushing your app to Heroku

Heroku References :

Heroku Deployment

Using .gitignore section

Cedar-14 Stack

Deploying with Git

Pay particular attention to the Cedar-14 Stack information.
Before you push your master branch to the production or staging environment

on Heroku, you will want to precompile your app's Assets:

RAILS_ENV=production rake assets:precompile

This one command will affect the master branch and we will pushing it to two

Heroku remote addresses, one for staging, one for production.
When it is done, remember to run git add and git commit before you push

your master branch to git.
Your assets are compiled ..

Your Gemfile shows to be invulnerable! ..

Your git status is clean on your master branch ..
Push your master branch to git : no other branches are affected or uploaded:

git push origin master

git push origin master --app visitmeet
You just pushed your master branch to the address showing for your origin remote:

git remote -v
Now we turn our attention to adding Heroku's staging environment remote address.

Heroku's Multiple Environments makes this easy peasy lemon squeezey to do.

IMPORTANT Heroku Note: "Forking an app will provision the same add-ons on the forked app

that you had on the original. These will be billable, so be sure to delete add-ons

on the forked app that you do not wish to be billed for later."

The visitmeet app currently uses, and will be using no paid add-ons.

This allows you to begin developing your fork entirely free.
Run these next three commands and read the responses carefully:

heroku create --remote staging

Heroku Note: "By default, the Heroku CLI creates projects with a heroku git remote

(thus the normal git push heroku master). Here, we’re specifying a

different name with the --remote flag, so pushing code to Heroku and

running commands against the app look a little different than the

normal git push heroku master:"

git push staging master
heroku ps --remote staging
Run the migrations on staging:

heroku run --remote staging bundle exec rake db:migrate
Heroku: "You will need to do some work to keep these apps in sync as you continue to develop them.

You’ll need to add contributors, config vars, and add-ons to each individually, for instance."
Congratulations, you now have your staging area set up, and you will now add the environment variables.

Question: What is the Heroku reference that contains the answer to the question

of how to distinguish the staging environment variables and the production, when

setting the environment variables ?
ANSWER: Heroku's Multiple Environments,

and we do so below.

Now you add the configuration variables to your staging remote:

Template:

heroku config:set DOMAIN_NAME=visitmeet.herokuapp.com --remote staging

heroku config:set S3_KEY=XXX --remote staging

heroku config:set S3_SECRET=YYY --remote staging

heroku config:set STRIPE_API_KEY=sk_test_longnumber --remote staging

heroku config:set STRIPE_PUBLISHABLE_KEY=pk_test_longnumber --remote staging

etc.

Multiple applications ?

Template:

heroku config:set DOMAIN_NAME=visitmeet.herokuapp.com --app visitmeet --remote staging

heroku config:set S3_KEY=XXX --app visitmeet --remote staging

heroku config:set S3_SECRET=YYY --app visitmeet --remote staging

heroku config:set STRIPE_API_KEY=sk_test_longnumber --app visitmeet --remote staging

heroku config:set STRIPE_PUBLISHABLE_KEY=pk_test_longnumber --app visitmeet --remote staging

etc.

If you make an error:

heroku config:set RAILS_ENV=prodctuion --remote staging --app visitmeet

You can unset the variable to remove it with:

heroku config:unset RAILS_ENV=prodctuion --remote staging --app visitmeet

and then reset it properly:

heroku config:set RAILS_ENV=production --remote staging --app visitmeet
Author note:

Is your Heroku staging remote now fully set up and fully working in your browser ?

You are ready to go into production with the simplest of front page and links.

The app is not yet ready to do ecommerce as we have not set up our SSL Certificate.
Heroku Note:

"Once your staging app is up and running properly, you can create your production app remote:"

heroku create --remote production
Run these next commands, reading the responses with care:
heroku create --remote production

To see your new remote address just created, run:

git remote -v

You will see the http | https addresses created match the

name created in the heroku create command.

git push production master

heroku ps --remote production
Run the migrations on production:

heroku run --remote production bundle exec rake db:migrate

How do you remove a remove a remote you created?

git remove rm remotename

Little by little, step by step, we continue ..
Add the configuration variables to your Heroku remote named production:

Template:

heroku config:set DOMAIN_NAME=visitmeet.herokuapp.com --remote production

heroku config:set S3_KEY=XXX --remote production

heroku config:set S3_SECRET=YYY --remote production

heroku config:set STRIPE_API_KEY=sk_live_longnumber --remote production

heroku config:set STRIPE_PUBLISHABLE_KEY=pk_live_longnumber --remote production

etc.
For Multiple Apps, add  --app appname to the lines.
Heroku Note: "You will need to do some work to keep these apps in sync as you continue to develop them.

You’ll need to add contributors, config vars, and add-ons to each individually, for instance."
"And with that, you’ve got the same codebase running as two separate Heroku apps ..

one staging and one production, set up identically."
Do you have any add-ons on the app now?

If you do, they must be added to both staging and production.
Your staging environment is now set up and you have already pushed to it.

Your production environment is now set up and you have pushed to it.

Verify your new remote addresses for Heroku's staging and production remotes with:

git remote -v

You should see the staging and production remotes have been added:
TODO : 20160126 : more to do in this area still

I advise studying this link, as it is new with the Cedar-14 stack now in place:

Heroku Multiple Environments
Run this command to see your current configs in your staging area:

TODO: Is this correct to show both environments?

heroku config --app visitmeet

Both configs for staging and production should show.
TODO: Verify the above statement is correct.
Add your configurations as required to run your app.

The Heroku Staging environment is where you can add the Mandrill API test-key.

Here I provide a sample of possible configuration variables you might use.  You

may not need all of these.:
  
$ heroku config --app visitmeet
=== visitmeet Config Vars
ADMIN_EMAIL:
ADMIN_NAME:
ADMIN_PASSWORD:
DATABASE_URL:             # we will soon be creating this
DEVISE_SECRET:
DOMAIN_NAME:              visitmeet.herokuapp.com
GEM_PATH:                 vendor/bundle/ruby/1.9.1         # TODO : Reference source ??
GMAIL_PASSWDRD:
GMAIL_USERNAME:
LANG:                     en_US.UTF-8
MAILCHIMP_API_KEY:
MAILCHIMP_LIST_ID:
MAILCHIMP_USERNAME:
# MANDRILL_API_KEY:       Generate and use a Mandrill production key here for your production environment
MANDRILL_API_KEY:         Generate and use a Mandrill test key here for your development and staging environment
MANDRILL_USERNAME:
OWNER_EMAIL:
PATH:                     bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin # TODO: ref ?
RACK_ENV:                 production                        # see note below code
RAILS_ENV:                production                        # see note below code 
RAILS_SERVE_STATIC_FILES: enabled
ROLES:                    [admin, silver, gold, platinum]   # if you have roles, place them here.
SECRET_KEY_BASE:          your_very_long_key
SECRET_TOKEN:
STRIPE_API_KEY:           sk_test_
STRIPE_PUBLISHABLE_KEY:   pk_test_
  

IMPORTANT HEROKU NOTE: "You should use RAILS_ENV=production or RACK_ENV=production for

your staging applications to minimize surprises while deploying to production. Read Deploying

to a custom Rails environment for more information."


SECOND IMPORTANT HEROKU NOTE: When you push to push to the Heroku master,

using git push heroku master on a single app,

or git push heroku master --app visitmeet if you have multiple apps,

or git push heroku master --app visitmeet --remote production ..

"The following additional environment variables will be set:
RAILS_ENV => 'production'

RACK_ENV => 'production'"

and ..
"A dev database add-on is provisioned if the Ruby application has the pg gem in the Gemfile. This populates the DATABASE_URL environment var."
Conclusion ..
Upon creation of the --remote staging, Heroku set both

the RACK_ENV and

the RAILS_ENV to production.
Per the above instructions, we should change it to one OR the other, in staging.
We are using the RAILS_ENV choice for our Rails app in the --remote staging area.

We will be setting the RAILS_ENV config in our --remote staging with this:

heroku config:add RAILS_ENV=staging # TODO: VERFIY BEFORE I RUN IT
To repeat, we will be pushing the master branch to Heroku

using two different remote addresses,

one named staging, for testing the app workings in a browser, and

one named production, live on the net as served by Heroku.
Push your staging branch to your new staging environment on Heroku:

Template usage:

git push heroku master --remote staging

git push heroku master --remote staging --app myappname
Our usage:

git push heroku master
git push heroku master --remote staging
We open our app on the address of:

http://visitmeet.herokuapp.com
When you are ready to push to your production environment, run:

git push heroku master --remote production
git push heroku master --remote production --app visitmeet

QUESTION: Is there a different browser address for the Heroku staging environment ?

ANSWER: TODO: seems there has to be, so find answer and reference : 20160126
A guess:

heroku open --remote staging

heroku open --app visitmeet --remote staging
heroku open --remote production

heroku open --app visitmeet --remote production
THE ANSWER TO How to Open the app in a web browser:
heroku apps:open

heroku apps:open --app visitmeet
and now that our app has two remotes, two environments,

we must tell Heroku which remote we want to open:
heroku apps:open --app visitmeet
heroku apps:open --app visitmeet --remote staging


Use heroku ps to show the Heroku processes for your app, including your dynos.
heroku ps


Use watch heroku ps to monitor your dynos in real time.
watch heroku ps


Use heroku status to display the status of your Heroku platform:
heroku status


Use heroku logs -t to monitor (tail) your logs in real time.
heroku logs -t

Press Control + c to exit tailing the logs.


Use heroku addons:open addon-name to open your browser to that addon's dashboard
heroku addons:open zerigo

You will be using this command later in these instructions, after we add the Zerigo add-on.

Next, we set up the Heroku Environment Configs for our app.
For more details on any command:

heroku help COMMAND

TODO: NOTE: ALL of the following CONFIG info now needs to be moved up and adjusted

to account for the  staging and production environments.

Setting Up Heroku Environment Configuration Variables


How Heroku Works : Config Vars

Templates to add configuration variables if you have only one app:

heroku config:set key1=value1

heroku config:set key1=value1 key2=value2

These examples show the truth of the Rule of the Three:

If you can do something once, you can do it a second time, and

If you can do it a second time, you can do it a third, and so on.

heroku config:set key1=value1 key2=value2 key3=value3

Templates to add configuration variables if you have more than one app:

heroku config:set key1=value1 --app visitmeet

heroku config:set key1=value1 key2=value2 --app visitmeet

Use the above Rule of the Three if you want to add a lot of variables at once.

Templates to remove configuration variables if you have more than one app:

heroku config:unset key1 --app visitmeet

heroku config:unset key1 key2 --app visitmeet

Example usage:

heroku config:unset GITHUB_USERNAME

Template to retrieve a configuration variable:

heroku config:get GITHUB_USERNAME

Now that you know how to do this from your Terminal,

know that you can also do this from your Heroku Dashboard.

"You can also edit config vars on your app’s settings tab on your dashboard"
Show your app configuration variables:

heroku config

heroku config --app visitmeet

Show detailed app information:

heroku apps:info

heroku apps:info --app visitmeet

Open the app in a web browser:

heroku apps:open

heroku apps:open --app visitmeet

Rename the app if you have one app:

heroku apps:rename newname

Identifies app to rename when you have more than one:

heroku apps:rename newname --app currentname

Configuration Variables you will need to enter.

Your /config/secrets.yml file will look similar to this:

Do not keep production secrets in the repository,

instead read values from the environment.


production:

admin_name: <%= ENV["ADMIN_NAME"] %>

admin_email: <%= ENV["ADMIN_EMAIL"] %>

admin_password: <%= ENV["ADMIN_PASSWORD"] %>

bank_account_number: <%= ENV["BANK_ACCOUNT_NUMBER"] %>

email_provider_username: <%= ENV["MAILCHIMP_USERNAME"] %>

email_provider_password: <%= ENV["MAILCHIMP_PASSWORD"] %>

domain_name: <%= ENV["DOMAIN_NAME"] %>

mailchimp_api_key: <%= ENV["MAILCHIMP_API_KEY"] %>

mailchimp_list_id: <%= ENV["MAILCHIMP_LIST_ID"] %>

stripe_api_key: <%= ENV["STRIPE_API_KEY"] %>

stripe_publishable_key: <%= ENV["STRIPE_PUBLISHABLE_KEY"] %>

secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

owner_email: <%= ENV["OWNER_EMAIL"] %>


staging:

admin_name: <%= ENV["ADMIN_NAME"] %>

admin_email: <%= ENV["ADMIN_EMAIL"] %>

admin_password: <%= ENV["ADMIN_PASSWORD"] %>

bank_account_number: <%= ENV["BANK_ACCOUNT_NUMBER"] %>

email_provider_username: <%= ENV["MANDRILL_USERNAME"] %>

email_provider_password: <%= ENV["MANDRILL_PASSWORD"] %>

domain_name: <%= ENV["DOMAIN_NAME"] %>

mailchimp_api_key: <%= ENV["MAILCHIMP_API_KEY"] %>

mailchimp_list_id: <%= ENV["MAILCHIMP_LIST_ID"] %>

stripe_api_key: <%= ENV["STRIPE_API_KEY"] %>

stripe_publishable_key: <%= ENV["STRIPE_PUBLISHABLE_KEY"] %>

secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

owner_email: <%= ENV["OWNER_EMAIL"] %>

Adding the configuration variables to the Heroku environment for your app.

You can also edit config vars on your app’s settings tab on your Heroku Dashboard:

heroku config:set admin_name=Johnny App

heroku config:set admin_email=yours@yours.com

heroku config:set admin_password=y0urPassw0rd

heroku config:set bank_account_number=forStripeUse

heroku config:set email_provider_username=mandrilluserName # if you use Mandrill

heroku config:set email_provider_password=mandrilluserPassword # if you use Mandrill

heroku config:set email_provider_username=gmailuserName # if you use Gmail

heroku config:set email_provider_password=gmailuserPassword # if you use Gmail

heroku config:set domain_name=yourdomainname

heroku config:set github_username=yourusername

heroku config:set github_password=yourpassword

heroku config:set mailchimp_api_key=api-key

heroku config:set mailchimp_list_id=list-id

heroku config:set owner_email=ownersemail

heroku config:set stripe_api_key=stripe-secret-key

heroku config:set stripe_publishable_key=stripe-public-key

heroku config:set secret_key_base=yoursecretkey

Older versions of the Heroku Toolbelt used config:add and config:remove.
To delete Heroku configuration variables:

heroku config:unset owner_email=ownersemail

To see your app's IP address, email handler and name alias at Heroku:

host www.yourdomainname.com

Heroku will ask for your credentials:

heroku login

Your terminal will tail the logs on your solitary, or named app:

heroku logs -t

heroku logs -t --app visitmeet

Takes your app offline for maintenance:

heroku maintenance:on

heroku maintenance:on --app visitmeet

Takes your app online, out of maintenance mode:

heroku maintenance:off

heroku maintenance:off --app visitmeet

Before you push your master to Heroku, you will want to precompile your app's Assets:

RAILS_ENV=production rake assets:precompile

RAILS_ENV=staging rake assets:precompile
Before you push your master to Heroku, you will need to add their remote address:

Template : using HTTPS transfer address:

git remote add https://heroku.com/bishisht/visitmeet.git

git remote add heroku git@heroku.com:appname.git
Our usage:

git remote add heroku git@heroku.com:visitmeet.git
Push your master to git : no other branches are affected or uploaded:

git push origin master

git push origin master --app visitmeet # verify this is required
Push your master to Heroku : no other branches are affected or uploaded:

git push heroku master

git push heroku master --app visitmeet

To see more info on Heroku Deployment

Lists all running processes and identifies state of each individual process:

heroku ps

heroku ps --app visitmeet

Shows Heroku version:

heroku version

heroku version --app visitmeet

Updates Heroku regarding your app:

heroku update

heroku update --app visitmeet

Shows info on your application:

heroku info

heroku info --app visitmeet

Shows configuration details for app:

heroku config

heroku config --app visitmeet

Heroku Configuration Details

TODO: This command needs to be verified that it is the current command.

20160115 : one change made, config:add is no longer used, config:set replaces it.

Do not be deceived by /ruby/1.9.1/ thinking it relates to Ruby-1.9.1, for it does not.

heroku config:set PATH=bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin

TODO: will --app visitmeet switch be required, this is a one time setup so my answer is not required.

heroku config:set PATH=bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin --app visitmeet

TODO: This command needs to be verified AND COMPARED TO THOSE FURTHER ABOVE.
remote heroku added, failing-wind-#### type name provided by Heroku:

heroku git:remote -a falling-wind-1624

heroku git:remote -a falling-wind-1624 --app visitmeet

TODO: This needs to be moved : 20160202
To remove a remote:

git remote rm filefetch

TODO: Find definition:

heroku keys

heroku keys --app visitmeet

TODO: Find definition:

heroku rake about

heroku rake about --app visitmeet

Shows you all your rake commands:

heroku rake -T

heroku rake -T --app visitmeet

Two commands for connection to console and database access:

heroku run console

heroku run console --app visitmeet
Heroku Reference : heroku run

heroku run rails console

heroku run rails console --app visitmeet


Both arrive at the same prompt:

will-i-am:visitmeet William$ heroku run console --app visitmeet

Running console on visitmeet... up, run.2773

Loading production environment (Rails 4.2.5.1)

irb(main):001:0>


This also works:

will-i-am:visitmeet William$ heroku run rails console --app visitmeet

Running rails console on visitmeet... up, run.2288

Loading production environment (Rails 4.2.5.1)

irb(main):001:0>


To exit from the heroku console:

exit

Shows aggregated logs for all components in the application stack:

heroku logs -t

heroku logs -t --app visitmeet

Component and process-level introspection:

heroku logs --ps worker.1 -t

heroku logs --ps worker.1 -t --app visitmeet

Opens your app in your default browser:

heroku open

heroku open --app visitmeet

Shows how many releases have you pushed to Heroku repository:

heroku releases

heroku releases --app visitmeet

Example:

heroku releases --app visitmeet

=== visitmeet Releases (made up example)

v255  Rollback to v253 : your email address : 2015/12/12 10:09:53

v254  Deploy 3e96d64   : your email address : 2015/12/12 10:05:30

v253  Deploy 20cae7f   : your email address : 2015/12/11 23:21:19

v252  Deploy da616dd   : your email address : 2015/12/04 16:19:25

v251  Remove TINFOILSECURITY_SCAN_SCHEDULE c.. : your email address : 2015/12/02 11:29:39

For more information on a release:

heroku releases:info v251
Before you do rollbacks, become very familiar with .
Heroku Note : Running on a rolled-back release is meant as a temporary fix to a bad deployment. If you are on a rolled-back release, fix and commit the problem locally, and re-push to Heroku to update the heroku Git remote and create a new release.
Undo errant modifications with Heroku Rollback to previous version:
heroku rollback

Heroku Nuance : If you have multiple apps, it is not required to use

heroku rollback --app visitmeet because your heroku remote address knows

what app it is addressing. Prove this to yourself by running: git remote -v .

Rollback to version v253:

heroku rollback v253

Information for version v252:

heroku releases:info v252

Setting Up the Database

Heroku Postgres Database

Heroku Postgres Everything

Heroku Connecting in Ruby

Verify the PG gem is in Gemfile and config/database.yml file for production

If you just now changed it to gem 'pg' now run:

bundle install

This will "download and resolve all dependencies."
You can use three commands to check your data, as you progress and after you finish:

cat config/database.yml

echo $DATABASE_URL

bin/rails runner 'puts ActiveRecord::Base.configurations'
A Nuance:

In the config/database.yml file, we set Postgres as our database in development,

test and production. We do this on our production app, so we know we are running on

Postgres all the time while we continue development and testing over the long term.

Heroku has a note on how to use PostgreSQL locally in development. Use this to adjust

your config/database.yml file:

  
development:
  adapter: postgresql
  host: localhost
  encoding: unicode # TODO: we are running utf-8, is this a problem ?
  # username: your_username_on_mac : you will be seeding these values with db/seed.rb
  # database: visitmeet-development : you will be seeding these values with db/seed.rb
  

The above is the template from Heroku Contacting in Ruby.
  
production:
  adapter: postgresql
  host: localhost
  encoding: unicode
  # username: your_username_on_mac  : we are setting Heroku configs directly to environment
  # database: visitmeet_production : ditto
  pool: 5
  

staging:
  adapter: postgresql
  host: localhost
  encoding: unicode
  pool: 5
  

production:
  adapter: postgresql
  host: localhost
  encoding: unicode
  pool: 5
  

If you had to set your username, do you know how to find the name ?

Open any Terminal and you will see it, mine looks like this:

will-i-am:visitmeet William$
My user name is William.
Create the database

The command uses the config/database.yml environment settings to create the database:
heroku run rake db:create
Do not run heroku run with db:create:all to create all databases in the config.

You do not need or even want to run this command on Heroku. A bit later,

we will be showing the commands to run to set up the Staging Area of your app on Heroku.

This is a no-no heroku run rake db:create:all so do not use it.

Drops the database for the current Rails.env and for our uses with Heroku, that will be

either Production, or Staging.

heroku run rake db:drop

You do not need to apply the --app appname switch because your heroku remote address knows.

When in doubt, run git remote -v and you will know.

The Heroku Database is Postgres.

After you set up the database with Heroku, these two commands:

heroku config

heroku pg

will show you your database information, your plan,

your PG version, your tables and rows and data size etc.

Rarely used reset of PG DATABASE.

The pg:reset command lines are not verified as accurate.

Template:

heroku pg:reset NAME_by_HEROKU

Example:

heroku pg:reset database_name
We are beginning with the free Hobby Developer database.

Actual Usage: to be confirmed from Heroku database name assigned:

heroku pg:reset your_database_name
What is the name of your database ?

heroku addons

If you have a lot of addons and want only the postgresql:

heroku addons | grep postgresql
Because we have run the database create command we can now run these commands:

heroku config

=== visitmeet Config Vars

DATABASE_URL:             postgres://lettersletters:etc.

LANG:                     en_US.UTF-8

MAILCHIMP_API_KEY:        your_long_key_from_mailchimp
MAILCHIMP_LIST_ID:        your-list-identification-number

MAX_THREADS:              1

RACK_ENV:                 production

RAILS_ENV:                production

RAILS_SERVE_STATIC_FILES: enabled

SECRET_KEY_BASE:          yours

=== # TODO: find reference for MAX_THREADS being set to 1
Now, we verify again with the reference materials given, what to do next.
When in doubt, seek the --help switch

heroku addons --help
Please read all of the following commands before you run one:

Template to create an add-on resource:

heroku addons:create SERVICE:PLAN

Template example to create free database at Heroku:

heroku addons:create heroku-postgresql:hobby-dev

Template example to create free database at Heroku with the --as switch:

heroku addons:create heroku-postgresql:hobby-dev --as USERS_DB

We are going to choose the last command, and we will use the name, VISITMEET_DB

If you used this command in your app, you will need to change to YOURNAMED_DB.
Our actual command used to create our Heroku Database:

heroku addons:create heroku-postgresql:hobby-dev --as VISITMEET_DB
We just created our database on Heroku for our app.
If you have more than one app, Heroku will ask you to name the app:
heroku addons:create heroku-postgresql:hobby-dev --app visitmeet --as VISITMEET_DB

Running the rake db:setup commmand will now create the database,

load the schema, and initialize with the seed data.

When you wish, you can use rake db:reset to drop the db first and then it does the setup.
heroku run rake db:setup is the right command to run on first setting up,

and simply performs both of the next two below.
Use Migrate when you add migrations to your production app.

Use db:seed when you add or change your db/seed.rb data.

heroku run rake db:migrate

heroku run rake db:seed
After your first use of the heroku rake db:setup command, or if you prefer you can

run the db:migrate, then the db:seed commands, in that order, your

subsequent use of the db:seed command would be rare or nil. You could run

the command to seed data into the database after you are in production, but

why ? TODO: Answer this question

CAUTION: The rake db:reset command drops the database first, then

creates the new database, loads the schema, initializes with the seed data.

This command is useful when you are first entering your site onto Heroku,

before you let the world know about it .. you can make all the tests in real

data and time to prove your site is ready, in staging and production, then run the

reset command, before your first real visitor signs up, after your invitations.

As a very last step, before going into full production, run this command and make sure

the app can run it in your staging area, and when you first set up your production area.

After that, it would be very rare to reset the database after going into production.

heroku run rake db:reset

The Heroku Procfile and Deploying to Heroku

This full document deserves your full study if you decide to use the Profile.

"A Procfile is not necessary to deploy apps written in most languages supported by Heroku.

The platform automatically detects the language, and creates a default web process type

to boot the application server."

The Heroku Procfile Instructions

####### Heroku's Procfile Naming and Location Instructions
The VisitMeet Procfile currently in use.

"A Procfile is a file named Procfile.

It should be named Procfile exactly, and not anything else.

For example, Procfile.txt is not valid.

The file should be a simple text file.
The file must be placed in the root directory of your application.

It will not function if placed in a subdirectory."

####### Process types as templates

"A Procfile contains a number of process type declarations, each on a new line.

Each process type is a declaration of a command that is executed when a dyno of

that process type is started.
For example, if a web process type is declared, then when a dyno of this type

is started, the command associated with the web process type, will be executed.

This could mean starting a web server, for example.
As an example, a Rails application might have the following process type:"

web: bundle exec rails server -p $PORT

" For many apps, these defaults will be sufficient.

For more sophisticated apps, and to adhere to the recommended approach of

more explicitly declaring of your application’s required runtime processes,

you may wish to define your process types. For example,

Rails applications are supplied with an additional process type of this sort:

worker:  bundle exec rake jobs:work
You can verify these commands are run when you push the app to Heroku.
Now, just for fun, run:

heroku ps

will-i-am:visitmeet William$ heroku ps

=== web (Free): bundle exec puma -C config/puma.rb

web.1: up 2016/02/05 13:21:15 -0800 (~ 12m ago)

We are set up to make our first change in the database ..
As the administrator, you now go in and change your User email and password

to match the email and password for you as the admin in the heroku configs you set.

Our usage:

heroku run console
Now you are going to change your Admin email and password to make them secure.

user = User.find_by_email('YourSeededEmail@example.com')

user.email = 'myadminemail@myaddress.com'

user.password = 'realpassword'

user.password_confirmation = 'realpassword'

user.save!

adminuser = User.find_by_email('myadminemail@myaddress.com')

exit
You are now secure as the Administrator.

Keep the real password safe and out of public repositories.

Write it down if need be in some manner and know where it is.
To visit your site login with your new email and password, run:

heroku open
Or, open any browser to this address:

http://visitmeet.herokuapp.com
Sign in as the administrator.

If you encounter ANY ERROR OF ANY KIND, open a new Terminal window and

run this heroku command to tail your logs, and run the app through its paces.

Error will show in a format you can see and use to repair problems.
New Terminal:

heroku tail -f
When your site CloudFlare SSL Cert is ready,

you can open any browser to this address:

https://visitmeet.herokuapp.com

Heroku Custom Domain Names

When your domain name forwarding is in place you can also open this address:

https://www.visitmeet.com

DO NOT ATTEMPT THE FOLLOWING UNTIL you know your DNS setup is perfect.

Only then you can consider further setting up to open the address as:

Heroku strongly recommends using www as your home address.

https://visitmeet.com

Heroku Subdomains Reference

Also, when you know what you are doing with subdomains,

I believe you can open any refined address you create such as:

https://guides.visitmeet.com

https://tours.visitmeet.com

https://nepal.visitmeet.com

https://bangkok.visitmeet.com

https://cuba.visitmeet.com

https://himalayan.visitmeet.com

https://mayan.visitmeet.com

https://singapore.visitmeet.com

TODO: more commands to be entered ?

TODO: all commands verfied in order ?

TODO: is Setting Up the Database now complete ?
Setting Up the DNS

First, you absolutely want to understand the term, url canonicalization.

Before you go any further, and so you don't drown in new terms being used ..

I invite you to read the clearest material on this matter you will ever find,

because it is crucial you really understand how to set up your site so the

world's search engines can find it; this is Search Engine Optimization at its core:

SEO advice: url canonicalization by Matt Cutts, Google Engineer.

I repeat, with good reason and long learnings, do not move forward in this

'manual of doings' until the above is well read and well understood. From this,

you will know the full differences between these two, and what to do with them

in terms of your DNS settings, and showing which address to the world, and why:

https://www.visitmeet.com

https://visitmeet.com
Which would you choose, and what is the reason? If you cannot answer with certainty

on the matter, devour the url canonicaliztion info.


After that has been achieved, now you can devour this document:

Heroku Custom Domain Names

Also see Setting Up the Domain Name Forwarding further below.
Setting up our DNS is now being worked on, meanwhile ..

Do you know the meanings of the DNS acronym ?

Answer is: Domain Name Service

TODO: More instructions to be entered herein and they all come from the next link ..
CloudFlare Instructions

CloudFlare
You will need an account, which is free to begin. When you are ready to go into

production, requiring your SSL Certificate, that is when CloudFlare begins to charge.
Sign up at : CloudFlare Signup
Sign in at : CloudFlare Signin
TODO: CloudFlare instructions to be entered, meanwhile, study the references.
Setting Up the SSL Certificate

CloudFlare

Heroku SSL Cert Instructions

They are long and difficult and CloudFlare gives more value beyond SSL.

This is why we use CloudFlare.

Sign in at : CloudFlare Signin
Behold your dashboard with CloudFlare. Notice your options:

Overview
Analytics
DNS
Crypto
Firewall
Speed
Caching
Page Rules
Network
Traffic
Customize
Apps
Scrape Shield

We will be going through each on the list.


Overview


2. Analytics

3. DNS : Here is where you must be entirely accurate.
https://www.cloudflare.com/a/dns/visitmeet.com
TODO: Not yet set up so not verifiable.
We will be using the CloudFlare system to set DNS data required.
ALSO SEE : [ZERIGO DNS info[(https://devcenter.heroku.com/articles/zerigo_dns#managing-mx-and-other-host-records)
You will be setting up the following DNS data:
CNAME : visitmeet.com : is an alias of visitmeet.herokuapp.com
CNAME : www : is an alias of visitmeet.com
MX : visitmeet.com : mail handled by your Mandrill-provided_number.in1.mandrillapp.com
MX : visitmeet.com : mail handled by your Mandrill-provided_number.in2.mandrillapp.com
SPF : visitmeet.com : v=spf1 include:spf.mandrillapp.com ?all
TXT : visitmeet.com : 
TXT : visitmeet.com : google-site-verification=your-very-long-google-given_id
TXT : mandrill_domainkey : v=DKIM1; k=rsa; p=your-very-long-alpha-numeric-mandrill_domain_key


4. Crypto

5. Firewall

6. Speed

7. Caching

8. Page Rules

9. Network

10. Traffic

11. Customize

12. Apps

13. Scrape Shield
Setting Up the Domain Name Forwarding

Add the custom domain to your app with the heroku domains:add command.

Look up the Heroku-supplied DNS Target for your custom domain using your

CloudFlare Dashboard.
Template:

heroku domains:add mydomain.com
Example usage:

heroku domains:add myotherdomain.com
Our usage:

heroku domains:add visitmeet.com

Heroku Note

"This will automatically add an ALIAS record ‘mydomain.com’ to ‘heroku-app-url.herokuapp.com’.

An ALIAS record is a specific type that essentially lets us safely create a domain apex level

CNAME like behavior."
Once installed, any domain or subdomain names added or removed via the heroku command-line tool

will automatically be added to Zerigo’s globally distributed DNS servers. Updates happen instantly

and Heroku will always keep your DNS records correct, meaning you never need to worry about them again.
For example:
heroku domains:add foo.mydomain.com
This will automatically add the ALIAS record ‘mydomain.com’ to ‘heroku-app-url.herokuapp.com’ and

a CNAME record ‘foo.mydomain.com’ to ‘heroku-app-url.herokuapp.com’. If the ALIAS record already exists

then it just adds the CNAME.
Of course, you can also remove a domain or subdomain name at any time with:
heroku domains:remove foo.mydomain.com

Visit your Heroku Dashboard:

Template address (replace appname with your registered domain name:

https://dashboard.heroku.com/apps/appname/settings

Our usage:

https://dashboard.heroku.com/apps/visitmeet/settings

The domains command shows your Heroku DNS Target will be: visitmeet.herokuapp.com.

heroku domains
The response will look like this:

heroku domains

=== visitmeet Heroku Domain

visitmeet.herokuapp.com

Use this command if you have multiple apps:

heroku domains --app visitmeet

Example response:

=== pacific-falls-38044 Heroku Domain
pacific-falls-38044.herokuapp.com

will-i-am:visitmeet William$ heroku domains --app visitmeet
=== visitmeet Heroku Domain
visitmeet.herokuapp.com
Configure your app’s DNS provider to point to the Heroku-supplied DNS Target.

Domains can be added to both free and paid Heroku apps and adding domains does not

incur extra charges. We use the Zerigo free AddOn with Heroku Add-ons.

Study Heroku Custom Domain Names.

Shows you all add-ons you are currently using, first users should have none:
heroku addons

FIRST STEP in Setting Up Custom Domain Name:

'.. before you make any NameServer changes, as

described further below. Run this command from inside

your app to enable Heroku to use a custom domain for your app.'

heroku addons:add custom_domains:basic # TODO: reverify with :

Heroku Source

Verfied again + one more time ? remove notes ? || 'resolve why not' return
SECOND STEP is a ".. a one-time setup for your domain with your registrar,

configuring it to use Zerigo’s DNS servers."

Visiting the link, you will see the addresses of their DNS servers:

a.ns.zerigo.net # Denver, Colorado, USA

b.ns.zerigo.net # Washington, DC, USA

c.ns.zerigo.net # London, United Kingdom

d.ns.zerigo.net # Dallas, Texas, USA

e.ns.zerigo.net # Amsterdam, Netherlands

f.ns.zerigo.net # Singapore

"Now you can use these domains with any of your Heroku apps by way of the Zerigo DNS Add-on."

Heroku Note

If you already have custom domains defined when adding the Zerigo DNS add-on, DNS entries

for your existing custom domain names will automatically be added to Zerigo’s systems.
Heroku Note

If you have installed the add-on previously using the heroku addon:create command,

destroying does not call out to Zerigo and remove the account. You will need to use

heroku addon:destroy to remove to records/domains.
Template for adding addons:

When you have one app:

heroku addons:add name_of_addon

When you have multiple apps:

heroku addons:add name_of_addon --app namedapp

Heroku example usage:

heroku addons:create heroku-redis:hobby-dev

heroku addons:create heroku-redis:hobby-dev --app important_app

When you have multiple apps with both staging and production environments on Heroku:

heroku addons:add name_of_addon --remote staging --app namedapp

heroku addons:add name_of_addon --remote production --app namedapp

TODO: verify the above two commands as correct.

Our example usage if you have one app on Heroku with staging and production environments:

heroku addons:create zerigo_dns --remote staging

DO NOT RUN THIS NEXT ONE YET:

heroku addons:create zerigo_dns --remote production
Our example usage if you have multiple apps on Heroku:

TODO: verify the app switch is needed.

heroku addons:create zerigo_dns --remote staging --app visitmeet

DO NOT RUN THIS NEXT ONE YET:

heroku addons:create zerigo_dns --remote production --app visitmeet
Did it work ? How do you find out ? Run both of these commands and you will see

they both give the same result.  Reason is, we have not yet added the zerigo_dns

addon to our Heroku production remote:

heroku addons

heroku addons --remote staging
You should now see two Add-on's as referred to in the results:

heroku-postgresql (postgresql-clear-*****)  hobby-dev  free
 └─ as DATABASE

zerigo_dns (zerigo-dns-asymmetrical-*****)    free       free

 └─ as ZERIGO_DNS
We have now run the first command, and will be running the second command when we are ready:

heroku addons:create zerigo_dns --remote staging --app visitmeet
Do not run this next command yet :

heroku addons:create zerigo_dns --remote production --app visitmeet


Our actual usage:

heroku addons:create zerigo_dns --remote staging


heroku addons:create zerigo_dns --remote staging --app visitmeet

If you run this command, heroku open --remote production, you will see it fails.
This is because we have not yet and will not yet run this command:

heroku addons:create zerigo_dns --remote production


To see the list of Zerigo Plans available, run:

heroku addons:plans zerigo_dns


Using zerigo_dns is the default, and it means zerigo_dns:free

See Upgrading or Downgrading your Zerigo plan

I like verifying things have been created and things have been

destroyed or removed and so I ask, How do I destroy / remove this addon ?
To end our usage of an addon in the Heroku staging remote ..

I thought this command would work ..

heroku addons:destroy zerigo_dns --remote staging

because the heroku part of the command checks your remotes and

sees the address, and our command will tell it what remote to use.

Run git remote -v to see your remote addresses.
However the result we get is as follows:
heroku addons:destroy zerigo_dns --remote staging
 

 !    WARNING: Destructive Action

 !    This command will affect the app: pacific-falls-*****

 !    To proceed, type "pacific-falls-*****" or re-run this command with --confirm pacific-falls-*****
You will receive the same result if you run:  heroku addons:destroy zerigo_dns
The full command to remove the Zerigo DNS addon from our app identifies the remote address and

confirms the database address:

heroku addons:destroy zerigo_dns --remote staging --confirm pacific-falls-*****

You cannot yet end usage of an addon in the Heroku production remote:

heroku addons:destroy addon-name --remote production --confirm indian-rivers-*****
We have not yet added it, and yes, indian-rivers is a made up name.

Before you add or destroy any addon, I advise you to refer to its source materials and see if

their Documentation contains any additional information on removing their addon. I also

advise running your app through all tests before and directly after you add an addon and

yes, after you destroy it. We added New Relic, and removed it due to interference with our app's

operation, and unbeknownst to us, and our tests, the Relic addon was still interfering with our

site operation on our Subscription Sign Up modal. How can this be, you ask ? So did we.
After I noticed it, it took repeated long testing from every angle to see why the Relic was

still an active relic of interference in our production app, AFTER we followed their's, and

Heroku's instructions. Finally, after long failure at resolving it, it took long and repeat

conversations with the Relic source to determine the cause. Nowhere in their own Relic Removal

instructions will you find any mention of this lasting interference upon removal, and if your

app is not testing for it, your tests won't find it. Based on the Relic's advertising budget

mee thinks some folks want to own things. To our production app, they are an old relic of no use.

If your experience is different, congratulations. Keep the above in mind if and when you

destroy any addon.
You can run the heroku open command to open your application in your default browser, the

you will notice please, these two open the staging environment for your testing in the browser:

heroku open

heroku open --remote staging

These two open the production environment:

heroku open --app visitmeet

heroku open --app visitmeet --remote production
TODO: The above is the answer to a question elsewhere in the TODO's, find it, remove or merge.

See Heroku's Manage Domain Names for how to remove a domain name.

TODO: will more domain name commands will be coming ?
Setting Up Stripe

Stripe.com
TODO: insert the stripe information and commands
Setting Up Mandrill and MailChimp

Will your app be using these email services ?

If yes, Mandrill recommends signing up at Mandrill first,

and using your Mandrill user_name and password / key with MailChimp

as they are the same company providing their two services.
Note that Mandrill accounts opened after December 2015, require Domain Verification.

Mandrill provides all instructions in a clear manner, so do study the links given.

We're Making Domain Verification Mandatory
Mandrill API Documentation

Mandrill Getting Started

About Domain Verification

About DMARC

Mandrill Domain Verification is required if you use a custom domain for sending emails.

This is not required if you use an email such as anything @ gmail . com
Verify a domain on the Sending Domains page in your Mandrill account

or ..

Verify a domain on the Sending Domains page with the Mandrill API using the /senders/verify-domain endpoint

How to Add DNS Records for Sending Domains

Manage sending domains in your Mandrill account

About SPF and DKIM
We begin walking through the steps.

Study this MailChimp document, Before You Start
TODO: Not fully in order or complete yet:
Adding a Mandrill API Test Key

Where to Add the API Test Key

Test Mode

How to Confirm If an Email Was Actually Delivered

Mandrill Webhooks

Introduction to Mandrill's Webhooks
BE AWARE AS OF 20160206 THIS GIST IS NOT YET READY FOR PRIME TIME.

As you can see by the sparseness of some commands above.
Soon to be .. Congratulations ..


Your app is now in production on Heroku using Ruby on Rails

Welcome to the Stable Near Edge Riding Ruby on Rails

Three cheers for your Rails app's healths and sharing of knowledges and wealths - This Gister

Upgrade, upgrade, upgrade with Rails-applications-health-codes.md by This Gister

Rails Stable

Rails Edge

Rails Docs

Ruby on Rails Documentation

Open Source Initiative

You can know you have arrived, your Stripe empowered site is humming.
We end with a quote in honor of Open Source:

'. . . we have the golden present.

Now we are alive and kicking.

What should we do now?

Love all, serve all.'

Sri Sawmi Satchidananda

Setting Up Stellar

Now that you have your app in production and secure we highly recommend

your beginning the process of adding the Stellar Cryptocurrency

capabilities to your site, so that you are amoung those developers and

companies and groups who are replacing the corrupt financial systems of

capitalism, which is still creating sybarites aplenty on the face of Mother Earth,

all chasing false profits in the name of false prophets of many kinds.


Stellar is the API of human exchanges without ministerial controls

beyond the Consensus Protocol, able to be used by those shut out by current world banking.

This will replace what will are all suffering under cAPItalism as owned by so few.


Kathy Onu

Stellar empowers human exchange with no interference from any entity.

Be astounded, read what someone created for their use of Stellar with their friends.

That article is dated August 2014, and you are not late, no matter the date you read this.

The Stellar codes and commands are beyond the scope of this gist.

We are currently taking our own advice here and studying and coding up Stellar in Ruby,

the instructions are being kept in order of how we did it, and will be shared on our site's

Ruby Corner, which currently does not exist, at https://www.goodworksonearth.net.
There is still much work to do ..

20160206 : Verifiying Zerigo_dns addon and commands

20160205 : URL canonicalization material with links, Cleaned up heroku addons commands

20160204 : Set Heroku --staging remote and repository

20160203 : Format housekeepings, fixed incorrect set-url's to set

20160202 : More clarity on Heroku --remote staging and production commands and setup

20160129 : Database setups complete and working

20160126 : Continue the 20160126 TODO: notes

20160125 : Adding instructions for staging and production environments on Heroku

20160124 : Pushed last day's additions

20160119 : Working Mandrill setup commands and links, added PG notes, fixed errors on Heroku commands

20160118 : Working it

20160117 : Will be working i.

20160116 : Running the fork commands and setting up remotes, still fixing remote commands

20160116 : Doing a run through, will find the incorrect / missing codes and add here

20160115 : Heroku Toolbelt and other reference links, code updates

20160114 : work continues

20160113 : Adding MX and other host records

20160113 : Continue adding git remote info and commands. Zerigo addon for domain setup

20160112 : Added Stellar data

20160112 : Begain addressing Mandrill and MailChimp codes

20160111 : Continued adding and verifying Heroku and other codes

20160110 : Continued adding and verifying Heroku codes

20160109 : Continued adding and verifying Heroku codes

20160108 : Continued adding and verifying Heroku codes

20160107 : Began adding the Heroku codes

20160106 : Gist first setup
TODO: One thing missing, a key of keys, are the StripeHooks and the StellarHooks,

webhooks to be fully precise. You want your app to have your Stripe Webhooks in place,

and working. These will be another Gist perhaps, for we too need to master them and test them, still.

Meanwhile, a good search for Stripe Webhooks will give you other source links.
A final sharing, slow down your speed of reading, to stop and look it up, when you recognize any term

you do not understand, in programming and in your life's living. After learning of Stellar's service to

the world wiser in exchanges, I understood more and more the the sheer power of Webhooks, to the point

I wondered why so few I know in programming fully use them ?
I found the same question in Rails testing, I spent a good two years learning the testing languages and

I found the same question in terms of, why are so few programmers using and sharing their testings ?

Can you write a test that verifies a webhook event in your Stripe notifications of your account being paid into ?
Can you define an Event in Stripe.com's protocols ?

Become familiar with the stripe-ruby-mock gem.

It is a mocking / testing gem for working with all aspects of Stripe.

Well, almost all.

Their documentations states quite clearly, the gem does not yet address all Stripe API endpoints,

and this includes they do not address all Stripe event webhook notifications as yet.

The gem is actively being contributed to and can be mastered with a good bit of study.
Address of This Rails App Is Secure In Production On Heroku Gist is:

https://gist.github.com/kathyonu/3559c20a5da4a78d6438