You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To use this boilerplate, you'll need to take the following steps:
17
+
To use this as boilerplate, you'll need to take the following steps:
12
18
13
-
* 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)
19
+
* Don't fork or clone this repo! Instead, create a new, empty
20
+
directory on your machine and `git init` (or create an empty repo on
21
+
Github and clone it to your local machine)
14
22
* Run the following commands:
15
23
16
24
```
@@ -19,7 +27,9 @@ git fetch boilermaker
19
27
git merge boilermaker/master
20
28
```
21
29
22
-
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:
30
+
Why did we do that? Because every once in a while, `boilermaker` may
31
+
be updated with additional features or bug fixes, and you can easily
Now that you've got the code, follow these steps to get acclimated:
32
42
33
-
* Update project name and description in `package.json` and `.travis.yml` files
34
-
*`npm install`, or `yarn install` - whatever you're into
35
-
* 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)
36
-
* By default, running `npm test` will use `boilermaker-test`, while regular development uses `boilermaker`
37
-
* Create a file called `secrets.js` in the project root
43
+
* Update project name and description in `package.json` and
44
+
`.travis.yml` files
45
+
*`npm install`
46
+
* Create two postgres databases (`MY_APP_NAME` should match the `name`
47
+
parameter in `package.json`):
48
+
49
+
```
50
+
export MY_APP_NAME=boilermaker
51
+
createdb $MY_APP_NAME
52
+
createdb $MY_APP_NAME-test
53
+
```
38
54
39
-
* This file is `.gitignore`'d, and will _only_ be required in your _development_ environment
40
-
* Its purpose is to attach the secret env variables that you'll use while developing
41
-
* However, it's **very** important that you **not** push it to Github! Otherwise, _prying eyes_ will find your secret API keys!
55
+
* By default, running `npm test` will use `boilermaker-test`, while
56
+
regular development uses `boilermaker`
57
+
* Create a file called `secrets.js` in the project root
58
+
* This file is listed in `.gitignore`, and will _only_ be required
59
+
in your _development_ environment
60
+
* Its purpose is to attach the secret environment variables that you
61
+
will use while developing
62
+
* However, it's **very** important that you **not** push it to
63
+
Github! Otherwise, _prying eyes_ will find your secret API keys!
Linters are fundamental to any project - they ensure that your code has a consistent style, which is critical to writing readable code.
82
+
Linters are fundamental to any project. They ensure that your code
83
+
has a consistent style, which is critical to writing readable code.
57
84
58
-
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:
85
+
Boilermaker comes with a working linter (ESLint, with
86
+
`eslint-config-fullstack`) "out of the box." However, everyone has
87
+
their own style, so we recommend that you and your team work out yours
88
+
and stick to it. Any linter rule that you object to can be "turned
89
+
off" in `.eslintrc.json`. You may also choose an entirely different
1.`heroku git:remote your-app-name` You'll need to be a collaborator on the app.
126
+
1.`heroku create` or `heroku create your-app-name` if you have a
127
+
name in mind.
128
+
2.`heroku addons:create heroku-postgresql:hobby-dev` to add
129
+
("provision") a postgres database to your heroku dyno
95
130
96
-
### When you're ready to deploy
97
-
98
-
#### Option A: Automatic Deployment via Continuous Integration
131
+
***If you already have a Heroku app...**
99
132
100
-
(_**NOTE**: This step assumes that you already have Travis-CI testing your code._)
133
+
1.`heroku git:remote your-app-name` You'll need to be a
134
+
collaborator on the app.
101
135
102
-
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.
136
+
### Travis
103
137
104
-
1. Run `git checkout master && git pull && git checkout -b f/travis-deploy` (or use some other new branch name).
105
-
2. Un-comment the bottom part of `.travis.yml` (the `before_deploy` and `deploy` sections)
106
-
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`.
107
-
4. Install the Travis CLI tools by following [the instructions here](https://github.com/travis-ci/travis.rb#installation).
108
-
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!_
109
-
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".
8. Make a PR for the new branch, get it approved, and merge it into master.
138
+
_**NOTE**_ that this step assumes that Travis-CI is already testing your code.
139
+
Continuous Integration is not about testing per se – it's about _continuously
140
+
integrating_ your changes into the live application, instead of periodically
141
+
_releasing_ new versions. CI tools can not only test your code, but then
142
+
automatically deploy your app. This is known as Continuous Deployment.
143
+
Boilermaker comes with a `.travis.yml` configuration almost ready for
144
+
continuous deployment; follow these steps to the job.
112
145
113
-
That's it! From now on, whenever `master` is updated on GitHub, Travis will automatically push the app to Heroku for you.
146
+
1. Run the following commands to create a new branch:
114
147
115
-
#### Option B: Manual Deployment from your Local Machine
148
+
```
149
+
git checkout master
150
+
git pull
151
+
git checkout -b f/travis-deploy
152
+
```
116
153
117
-
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:
154
+
2. Run the following script to finish configuring `travis.yml` :
155
+
`npm run heroku-token`
156
+
This will use your `heroku` CLI (that you configured previously, if
157
+
not then see [above](#Heroku)) to generate an authentication token. It
158
+
will then use `openssl` to encrypt this token using a public key that
159
+
Travis has generated for you. It will then update your `.travis.yml`
160
+
file with the encrypted value to be sent with the `secure` key under
161
+
the `api_key`.
162
+
3. Run the following commands to commit these changes
118
163
119
-
1. Make sure that all your work is fully committed and pushed to your master branch on Github.
120
-
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
121
-
3.`npm run deploy` - this will cause the following commands to happen in order:
164
+
```
165
+
git add .travis.yml
166
+
git commit -m 'travis: activate deployment'
167
+
git push -u origin f/travis-deploy
168
+
```
122
169
123
-
*`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.
124
-
*`webpack -p`: webpack will run in "production mode"
_ `git commit --allow-empty -m 'Deploying'`: create a commit, even
212
+
if nothing changed
213
+
_ `git push --force heroku deploy:master`: push your local
214
+
`deploy` branch to the `master` branch on `heroku`
215
+
_ `git checkout master`: return to your master branch
216
+
_ `git branch -D deploy`: remove the deploy branch
130
217
131
218
Now, you should be deployed!
132
219
133
-
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!
220
+
Why do all of these steps? The big reason is because we don't want our
221
+
production server to be cluttered up with dev dependencies like
222
+
`webpack`, but at the same time we don't want our development
223
+
git-tracking to be cluttered with production build files like
224
+
`bundle.js`! By doing these steps, we make sure our development and
0 commit comments