Boilermaker

Good things come in pairs

Looking to mix up a backend with

express

sequelize

react

redux

boilermaker

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

Setup

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)
• Run the following commands:

git remote add boilermaker https://github.com/FullstackAcademy/boilermaker.git
git fetch boilermaker
git merge boilermaker/master

Why did we do that? Because every once in a while,

boilermaker

git fetch boilermaker
git merge boilermaker/master

Customize

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

• 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

• 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'

OAuth

• 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.

Linting

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

.eslintrc.json

• Standard style guide
• Airbnb style guide
• Google style guide

Start

Running

npm run start-dev

If you want to run the server and/or

webpack

npm run start-server

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 supported ways to deploy in Boilermaker:

• 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. The steps below are also covered in the CI/CD workshop.

Heroku

1. Set up the Heroku command line tools

2. heroku login

3. Add a git remote for heroku:

• If you are 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

• If you already have a Heroku app...

1. heroku git:remote your-app-name

   You'll need to be a collaborator on the app.

Travis

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

1. Run the following commands to create a new branch:

git checkout master
git pull
git checkout -b f/travis-deploy

1. 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) 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

   .
2. Run the following commands to commit these changes

git add .travis.yml
git commit -m 'travis: activate deployment'
git push -u origin f/travis-deploy

1. 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

heroku

git remote

Travis CLI

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

That's it! From now on, whenever

master

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

bundle.js