Build out and document contributing rules and QA process

[alexkyllo]

1. Deploy a second instance of the api app to Heroku to use as a staging and User Acceptance Testing environment - DONE
2. Create a CONTRIBUTING.md document to list rules and steps for contributing code to this repository - DONE
3. Build out a unit test suite for the domain logic in the client-side Javascript code
4. Document a series of manual UI regression tests to be run before deploying to production - DONE
5. Automate the UI tests using a Selenium-based browser automation framework
6. Set up Travis CI to automatically detect new commits to the repo, check out the code, run tests, and deploy. - DONE

[alexkyllo]

Staging site is up and running at https://curatescience-staging.herokuapp.com/beta

[alexkyllo]

@eplebel since you have admin rights, would you please go to https://travis-ci.org/profile/ScienceCommons (log in with your Github account) and click the button to enable ScienceCommons/www for Travis CI?

After you do that, I can set up Travis CI to watch the github repo for commits and deploy to staging automatically. I almost have this working with the api repo, which is already enabled, but I cannot do it for the www repo until you enable that one.

I will create a "staging" branch in each github repo and we can require developers to submit pull requests to that branch. Then all you'll have to do is merge the pull request and Travis will automatically grab the code, build the app, run any tests, and deploy to https://curatescience-staging.herokuapp.com/beta so you can UAT it. The deploy api keys will be securely stored in Travis and we won't need to distribute them to developers.

[eplebel]

Great! I just authorized Travis CI to have access to our github repos, let me know if you need anything else!

[alexkyllo]

Perfect, I can see both repos in the Travis interface now, thanks! I'll work on creating the build/test/deploy scripts.

[alexkyllo]

The api repo will now auto-deploy to heroku staging when a pull request is merged into the staging branch, and it will deploy to heroku production when a pull request is merged into the master branch. If and only if all the unit tests pass.

Working on setting up a similar process for the www repo.

[eplebel]

Sweet, that's awesome!!

So this effectively solves the Elance deploy problem we discussed on Sunday right (given I could merge PRs from an Elancer into the staging branch)?

[alexkyllo]

Yes, exactly--but currently only for the api repo, I'm still working on setting it up for www.

The Elancer will just need to be careful to open their pull requests on the staging branches, and you'll also want to be careful not to merge a pull request into master until you've merged it into staging and tested it first.

I'll let you know as soon as everything is set up and ready to fully switch over to this workflow. And I'll deploy Tetiana's latest pull requests to staging manually tonight.

[alexkyllo]

TravisCI now successfully deploys the www repo code to staging environment when it detects a commit to staging branch.

@eplebel I created a CONTRIBUTING.md file, please feel free to review it and give me any questions/feedback you or another contributor may have.

Note: If you're just updating documentation files on github, such as README.md or CONTRIBUTING.md and you don't want to trigger a Travis rebuild/redeploy, just add [ci skip] anywhere in your commit message and Travis will skip the build.