Code scaffold for projects
Good things come in pairs
Looking to mix up a backend with
sequelizeand a frontend with
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
To use this as 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,
boilermakermay 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:
MY_APP_NAMEshould match the
export MY_APP_NAME=boilermaker createdb $MY_APP_NAME createdb $MY_APP_NAME-test
npm testwill use
boilermaker-test, while regular development uses
secrets.jsin the project root
.gitignore, and will only be required in your development environment
process.env.GOOGLE_CLIENT_ID = 'hush hush' process.env.GOOGLE_CLIENT_SECRET = 'pretty secret' process.env.GOOGLE_CALLBACK = '/auth/google/callback'
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-devwill make great things happen!
If you want to run the server and/or
webpackseparately, you can also
npm run start-serverand
npm run build-client.
From there, just follow your bliss.
Ready to go world wide? Here's a guide to deployment! There are two supported ways to deploy in Boilermaker:
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 create your-app-nameif you have a name in mind.
heroku addons:create heroku-postgresql:hobby-devto add ("provision") a postgres database to your heroku dyno
heroku git:remote your-app-nameYou'll need to be a collaborator on the app.
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.ymlconfiguration almost ready for continuous deployment; follow these steps to the job.
git checkout master git pull git checkout -b f/travis-deploy
npm run heroku-tokenThis will use your
herokuCLI (that you configured previously, if not then see above) to generate an authentication token. It will then use
opensslto encrypt this token using a public key that Travis has generated for you. It will then update your
.travis.ymlfile with the encrypted value to be sent with the
securekey under the
git add .travis.yml git commit -m 'travis: activate deployment' git push -u origin f/travis-deploy
NOTE that this script depends on your local
originGit remote matching your GitHub URL, and your local
herokuremote 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 remoteand its related commands.
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
masteris updated on GitHub, Travis will automatically push the app to Heroku for you.
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 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.
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
deployhere is not magical, but it needs to match the name of the branch we specify when we push to our
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
git commit --allow-empty -m 'Deploying': create a commit, even if nothing changed _
git push --force heroku deploy:master: push your local
deploybranch to the
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!