Update release guide with git flow steps, update Travis deployment to use git tag

.travis.yml

@@ -38,6 +38,7 @@ deploy:
     skip_cleanup: true
     on:
       branch: release
+      tags: true
   - provider: script
     script: ./deploy_staging.sh
     skip_cleanup: true

deploy.sh

@@ -4,9 +4,9 @@ set -e
 
 docker-compose build --no-cache
 docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD"
-docker tag $APP_IMAGE_NAME $DOCKER_USERNAME/$DOCKER_REPOSITORY:$TRAVIS_COMMIT
+docker tag $APP_IMAGE_NAME $DOCKER_USERNAME/$DOCKER_REPOSITORY:$TRAVIS_TAG
 docker tag $APP_IMAGE_NAME $DOCKER_USERNAME/$DOCKER_REPOSITORY:latest
-docker push $DOCKER_USERNAME/$DOCKER_REPOSITORY:$TRAVIS_COMMIT
+docker push $DOCKER_USERNAME/$DOCKER_REPOSITORY:$TRAVIS_TAG
 docker push $DOCKER_USERNAME/$DOCKER_REPOSITORY:latest
 
 echo $GCLOUD_SERVICE_KEY_PRD | base64 --decode -i > ${HOME}/gcloud-service-key.json

developer_docs/development.md

@@ -15,7 +15,10 @@ A guide for adding code to this project.
 Follow the [installation guide](./installation.md).
 
 ## Development Workflow
-This project uses git-flow. For an in-depth overview of git-flow, read ["A successful Git branching model"](https://nvie.com/posts/a-successful-git-branching-model/). As a person contributing code but not creating production releases (this is most people!), here's what you need to know:
+* This project uses git-flow. For an in-depth overview of git-flow, read ["A successful Git branching model"](https://nvie.com/posts/a-successful-git-branching-model/).
+* [Let's stop saying Master/Slave](https://medium.com/@mikebroberts/let-s-stop-saying-master-slave-10f1d1bf34df)
+
+As a person contributing code but not creating production releases (this is most people!), here's what you need to know:
 * The default branch is `develop`. All pull requests should be made to this branch. It should be stable, and all commits are visible at a staging sever.
 * When working on a bug or feature, you should branch from the `develop` branch. When you're done, you should open a pull request from your feature branch to `develop`.
 * The `release` branch is the live production branch, and is the code deployed to editor.p5js.org. Changes to this branch should be made carefully, and will be done using git tags. 

developer_docs/release.md

@@ -7,5 +7,18 @@ This project release guide is based on
 * [git-flow](https://nvie.com/posts/a-successful-git-branching-model/)
 * [Semantic Versioning (semver)](https://semver.org/)
 * [npm-version](https://docs.npmjs.com/cli/version)
+* [Let's stop saying Master/Slave](https://medium.com/@mikebroberts/let-s-stop-saying-master-slave-10f1d1bf34df)
 
 ## Steps
+1. `$ git checkout develop`
+2. `$ git checkout -b release-<newversion>`
+3. Do all of the release branch testing necessary. This could be as simple as running `npm test:ci`, or it could take user testing over a few days. 
+4. `$ git checkout release`
+5. `$ git merge --no-ff release-<newversion>`
+6. `$ npm version <newversion>` (see [npm-version](https://docs.npmjs.com/cli/version) for valid values of <newversion>).
+7. `$ git push && git push --tags`
+8. `$ git checkout develop`
+9. `$ git merge --no-ff release-<newversion>`
+
+Travis CI will automatically deploy the release to production, as well as push a production tagged Docker image to DockerHub.
+