Good things come in pairs
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.
To use this boilerplate, you'll need to take the following steps:
git init
(or create an empty repo on Github and clone it to your local machine)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
may be updated with additional features or bug fixes, and you can easily get those changes from now on by entering:
git fetch boilermaker
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)
npm test
will use boilermaker-test
, while regular development uses boilermaker
Create a file called secrets.js
in the project root
.gitignore
'd, and will only be required in your development environmentprocess.env.GOOGLE_CLIENT_ID = 'hush hush'
process.env.GOOGLE_CLIENT_SECRET = 'pretty secret'
process.env.GOOGLE_CALLBACK = '/auth/google/callback'
To use OAuth with Google, complete the step above with a real client ID and client secret from Google
Finally, complete the section below to set up your linter
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:
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
.
From there, just follow your bliss.
Ready to go world wide? Here's a guide to deployment! There are two (compatible) ways to deploy:
Either way, you'll need to set up your deployment server to start:
heroku login
If you're creating a new app...
heroku create
or heroku create your-app-name
if you have a name in mind.heroku addons:create heroku-postgresql:hobby-dev
to add ("provision") a postgres database to your heroku dynoIf you already have a Heroku app...
heroku git:remote your-app-name
You'll need to be a collaborator on the app.(NOTE: This step assumes that you already have Travis-CI testing your code.)
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.
git checkout master && git pull && git checkout -b f/travis-deploy
(or use some other new branch name)..travis.yml
(the before_deploy
and deploy
sections)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
.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!.travis.yml
file under deploy.api_key.secure
, where it says "YOUR ENCRYPTED API KEY HERE".git add -A && git commit -m 'travis: activate deployment' && git push -u origin f/travis-deploy
That's it! From now on, whenever master
is updated on GitHub, Travis will automatically push the app to Heroku for you.
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:
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 errornpm 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 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 filesgit commit --allow-empty -m 'Deploying'
: create a commit, even if nothing changedgit push --force heroku deploy:master
: push your local "deploy" branch to the "master" branch on herokugit checkout master
: return to your master branchgit branch -D deploy
: remove the deploy branchNow, 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!