Skip to content

Commit

Permalink
feat(deployment): encrypt heroku auth token in node (#188)
Browse files Browse the repository at this point in the history 
* feat(deployment): encrypt heroku auth token in node

* bug(deployment): Included missing file and added error cleanup to heroku-token script
  • Loading branch information
@dakotablair
dakotablair authored Jul 23, 2019
1 parent 1904980 commit 878e5dd
Show file tree
Hide file tree
Showing 7 changed files with 1,398 additions and 1,152 deletions.
5 changes: 2 additions & 3 deletions .travis.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,8 @@ node_js:
services:
- postgresql # starts up postgres
addons:
postgresql: '9.6' # highest available postgres version on Travis
dist: trusty # uses trusty environment
sudo: false # when on trusty, uses Docker containers for speed
postgresql: '10' # recent postgres version on Travis
dist: xenial # uses xenial environment
notifications:
email:
on_success: change # default: change (only when going from broken to fixed)
Expand Down
220 changes: 156 additions & 64 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,23 @@

_Good things come in pairs_

Looking to mix up a backend with express/sequelize and a frontend with react/redux? That's `boilermaker`!
Looking to mix up a backend with `express`/`sequelize` and a frontend with
`react`/`redux`? That's `boilermaker`!

Follow along with the workshop to make your own! This canonical version can serve as a reference, or a starting point all on its own.
Follow along with the boilerplate workshop to make your own! This canonical
version can serve as a reference, or a starting point. For an in depth
discussion into the code that makes up this repository, see the
[Boilermaker Guided Tour][boilermaker-yt]

[boilermaker-yt]: https://www.youtube.com/playlist?list=PLx0iOsdUOUmn7D5XL4mRUftn8hvAJGs8H

## Setup

To use this boilerplate, you'll need to take the following steps:
To use this as boilerplate, you'll need to take the following steps:

* Don't fork or clone this repo! Instead, create a new, empty directory on your machine and `git init` (or create an empty repo on Github and clone it to your local machine)
* Don't fork or clone this repo! Instead, create a new, empty
directory on your machine and `git init` (or create an empty repo on
Github and clone it to your local machine)
* Run the following commands:

```
Expand All @@ -19,7 +27,9 @@ git fetch boilermaker
git merge boilermaker/master
```

Why did we do that? Because every once in a while, `boilermaker` may be updated with additional features or bug fixes, and you can easily get those changes from now on by entering:
Why did we do that? Because every once in a while, `boilermaker` may
be updated with additional features or bug fixes, and you can easily
get those changes from now on by entering:

```
git fetch boilermaker
Expand All @@ -30,104 +40,186 @@ git merge boilermaker/master

Now that you've got the code, follow these steps to get acclimated:

* Update project name and description in `package.json` and `.travis.yml` files
* `npm install`, or `yarn install` - whatever you're into
* Create two postgres databases: `boilermaker` and `boilermaker-test` (you can substitute these with the name of your own application - just be sure to go through and change the `package.json` and `.travis.yml` to refer to the new name)
* By default, running `npm test` will use `boilermaker-test`, while regular development uses `boilermaker`
* Create a file called `secrets.js` in the project root
* Update project name and description in `package.json` and
`.travis.yml` files
* `npm install`
* Create two postgres databases (`MY_APP_NAME` should match the `name`
parameter in `package.json`):

```
export MY_APP_NAME=boilermaker
createdb $MY_APP_NAME
createdb $MY_APP_NAME-test
```

* This file is `.gitignore`'d, and will _only_ be required in your _development_ environment
* Its purpose is to attach the secret env variables that you'll use while developing
* However, it's **very** important that you **not** push it to Github! Otherwise, _prying eyes_ will find your secret API keys!
* By default, running `npm test` will use `boilermaker-test`, while
regular development uses `boilermaker`
* Create a file called `secrets.js` in the project root
* This file is listed in `.gitignore`, and will _only_ be required
in your _development_ environment
* Its purpose is to attach the secret environment variables that you
will use while developing
* However, it's **very** important that you **not** push it to
Github! Otherwise, _prying eyes_ will find your secret API keys!
* It might look like this:

```
process.env.GOOGLE_CLIENT_ID = 'hush hush'
process.env.GOOGLE_CLIENT_SECRET = 'pretty secret'
process.env.GOOGLE_CALLBACK = '/auth/google/callback'
```
```
process.env.GOOGLE_CLIENT_ID = 'hush hush'
process.env.GOOGLE_CLIENT_SECRET = 'pretty secret'
process.env.GOOGLE_CALLBACK = '/auth/google/callback'
```

### OAuth

* To use OAuth with Google, complete the step above with a real client ID and client secret from Google
* You can get them here: https://console.developers.google.com/apis/credentials
* Finally, complete the section below to set up your linter
* To use OAuth with Google, complete the steps above with a real client
ID and client secret supplied from Google
* You can get them from the [Google APIs dashboard][google-apis].

[google-apis]: https://console.developers.google.com/apis/credentials

## Linting

Linters are fundamental to any project - they ensure that your code has a consistent style, which is critical to writing readable code.
Linters are fundamental to any project. They ensure that your code
has a consistent style, which is critical to writing readable code.

Boilermaker comes with a working linter (ESLint, with `eslint-config-fullstack`) "out of the box." However, everyone has their own style, so we recommend that you and your team work out yours and stick to it. Any linter rule that you object to can be "turned off" in `.eslintrc.json`. You may also choose an entirely different config if you don't like ours:
Boilermaker comes with a working linter (ESLint, with
`eslint-config-fullstack`) "out of the box." However, everyone has
their own style, so we recommend that you and your team work out yours
and stick to it. Any linter rule that you object to can be "turned
off" in `.eslintrc.json`. You may also choose an entirely different
config if you don't like ours:

* [Standard style guide](https://standardjs.com/)
* [Airbnb style guide](https://github.com/airbnb/javascript)
* [Google style guide](https://google.github.io/styleguide/jsguide.html)

## Start

`npm run start-dev` will make great things happen!
Running `npm run start-dev` will make great things happen!

If you want to run the server and/or webpack separately, you can also `npm run start-server` and `npm run build-client`.
If you want to run the server and/or `webpack` separately, you can also
`npm run start-server` and `npm run build-client`.

From there, just follow your bliss.

## Deployment

Ready to go world wide? Here's a guide to deployment! There are two (compatible) ways to deploy:
Ready to go world wide? Here's a guide to deployment! There are two
supported ways to deploy in Boilermaker:

* automatically, via continuous integration
* manually, from your local machine
* automatically, via continuous deployment with Travis.
* "manually", from your local machine via the `deploy` script.

Either way, you'll need to set up your deployment server to start:
Either way, you'll need to set up your deployment server to start.
The steps below are also covered in the CI/CD workshop.

### Prep
### Heroku

1. Set up the [Heroku command line tools](https://devcenter.heroku.com/articles/heroku-cli)
1. Set up the [Heroku command line tools][heroku-cli]
2. `heroku login`
3. Add a git remote for heroku:

* **If you're creating a new app...**

1. `heroku create` or `heroku create your-app-name` if you have a name in mind.
2. `heroku addons:create heroku-postgresql:hobby-dev` to add ("provision") a postgres database to your heroku dyno
[heroku-cli]: https://devcenter.heroku.com/articles/heroku-cli

* **If you already have a Heroku app...**
* **If you are creating a new app...**

1. `heroku git:remote your-app-name` You'll need to be a collaborator on the app.
1. `heroku create` or `heroku create your-app-name` if you have a
name in mind.
2. `heroku addons:create heroku-postgresql:hobby-dev` to add
("provision") a postgres database to your heroku dyno

### When you're ready to deploy

#### Option A: Automatic Deployment via Continuous Integration
* **If you already have a Heroku app...**

(_**NOTE**: This step assumes that you already have Travis-CI testing your code._)
1. `heroku git:remote your-app-name` You'll need to be a
collaborator on the app.

CI is not about testing per se – it's about _continuously integrating_ your changes into the live application, instead of periodically _releasing_ new versions. CI tools can not only test your code, but then automatically deploy your app. Boilermaker comes with a `.travis.yml` configuration almost ready for deployment; follow these steps to complete the job.
### Travis

1. Run `git checkout master && git pull && git checkout -b f/travis-deploy` (or use some other new branch name).
2. Un-comment the bottom part of `.travis.yml` (the `before_deploy` and `deploy` sections)
3. Add your Heroku app name to `deploy.app`, where it says "YOUR HEROKU APP NAME HERE". For example, if your domain is `cool-salty-conifer.herokuapp.com`, your app name is `cool-salty-conifer`.
4. Install the Travis CLI tools by following [the instructions here](https://github.com/travis-ci/travis.rb#installation).
5. Run `travis encrypt $(heroku auth:token) --org` to encrypt your Heroku API key. _**Warning:** do not run the `--add` command suggested by Travis, that will rewrite part of our existing config!_
6. Copy-paste your encrypted API key into the `.travis.yml` file under `deploy.api_key.secure`, where it says "YOUR ENCRYPTED API KEY HERE".
7. `git add -A && git commit -m 'travis: activate deployment' && git push -u origin f/travis-deploy`
8. Make a PR for the new branch, get it approved, and merge it into master.
_**NOTE**_ that this step assumes that Travis-CI is already testing your code.
Continuous Integration is not about testing per se – it's about _continuously
integrating_ your changes into the live application, instead of periodically
_releasing_ new versions. CI tools can not only test your code, but then
automatically deploy your app. This is known as Continuous Deployment.
Boilermaker comes with a `.travis.yml` configuration almost ready for
continuous deployment; follow these steps to the job.

That's it! From now on, whenever `master` is updated on GitHub, Travis will automatically push the app to Heroku for you.
1. Run the following commands to create a new branch:

#### Option B: Manual Deployment from your Local Machine
```
git checkout master
git pull
git checkout -b f/travis-deploy
```

Some developers may prefer to control deployment rather than rely on automation. Your local copy of the application can be pushed up to Heroku at will, using Boilermaker's handy deployment script:
2. Run the following script to finish configuring `travis.yml` :
`npm run heroku-token`
This will use your `heroku` CLI (that you configured previously, if
not then see [above](#Heroku)) to generate an authentication token. It
will then use `openssl` to encrypt this token using a public key that
Travis has generated for you. It will then update your `.travis.yml`
file with the encrypted value to be sent with the `secure` key under
the `api_key`.
3. Run the following commands to commit these changes

1. Make sure that all your work is fully committed and pushed to your master branch on Github.
2. If you currently have an existing branch called "deploy", delete it now (`git branch -d deploy`). We're going to use a dummy branch with the name "deploy" (see below), so if you have one lying around, the script below will error
3. `npm run deploy` - this will cause the following commands to happen in order:
```
git add .travis.yml
git commit -m 'travis: activate deployment'
git push -u origin f/travis-deploy
```

* `git checkout -b deploy`: checks out a new branch called "deploy". Note that the name "deploy" here isn't magical, but it needs to match the name of the branch we specify when we push to our heroku remote.
* `webpack -p`: webpack will run in "production mode"
* `git add -f public/bundle.js public/bundle.js.map`: "force" add the otherwise gitignored build files
* `git commit --allow-empty -m 'Deploying'`: create a commit, even if nothing changed
* `git push --force heroku deploy:master`: push your local "deploy" branch to the "master" branch on heroku
* `git checkout master`: return to your master branch
* `git branch -D deploy`: remove the deploy branch
4. Make a Pull Request for the new branch, get it approved, and merge it into
the master branch.

_**NOTE**_ that this script depends on your local `origin` Git remote matching
your GitHub URL, and your local `heroku` remote matching the name of your
Heroku app. This is only an issue if you rename your GitHub organization,
repository name or Heroku app name. You can update these values using
`git remote` and its related commands.

#### Travis CLI

There is a procedure to complete the above steps by installing the official
[Travis CLI tools][travis-cli]. This requires a recent Ruby, but this step
should not be, strictly speaking, necessary. Only explore this option when the
above has failed.

[travis-cli]: https://github.com/travis-ci/travis.rb#installation

That's it! From now on, whenever `master` is updated on GitHub, Travis
will automatically push the app to Heroku for you.

### Cody's own deploy script

Your local copy of the application can be pushed up to Heroku at will,
using Boilermaker's handy deployment script:

1. Make sure that all your work is fully committed and merged into your
master branch on Github.
2. If you currently have an existing branch called "deploy", delete
it now (`git branch -d deploy`). We will use a dummy branch
with the name `deploy` (see below), so and the script below will error if a
branch with that name already exists.
3. `npm run deploy`
_ this will cause the following commands to happen in order:
_ `git checkout -b deploy`: checks out a new branch called
`deploy`. Note that the name `deploy` here is not magical, but it needs
to match the name of the branch we specify when we push to our `heroku`
remote.
_ `webpack -p`: webpack will run in "production mode"
_ `git add -f public/bundle.js public/bundle.js.map`: "force" add
these files which are listed in `.gitignore`.
_ `git commit --allow-empty -m 'Deploying'`: create a commit, even
if nothing changed
_ `git push --force heroku deploy:master`: push your local
`deploy` branch to the `master` branch on `heroku`
_ `git checkout master`: return to your master branch
_ `git branch -D deploy`: remove the deploy branch

Now, you should be deployed!

Why do all of these steps? The big reason is because we don't want our production server to be cluttered up with dev dependencies like webpack, but at the same time we don't want our development git-tracking to be cluttered with production build files like bundle.js! By doing these steps, we make sure our development and production environments both stay nice and clean!
Why do all of these steps? The big reason is because we don't want our
production server to be cluttered up with dev dependencies like
`webpack`, but at the same time we don't want our development
git-tracking to be cluttered with production build files like
`bundle.js`! By doing these steps, we make sure our development and
production environments both stay nice and clean!
Loading

0 comments on commit 878e5dd

Please sign in to comment.