CI & Deployment

Master Branch is what is deployed to production servers. Code checked in to github master branch that passes tests and pylint will be automatically pushed to heroku. First, the JS and CSS will be automatically compressed and transferred to S3, the code will be pushed to heroku, and then migrations will be run and collect static will be run. No precompressed JS or CSS or manifests should be checked into git any longer. Code that does not pass tests or pylint will not and should not be deployed. No one should directly push code to heroku - all deploys should go through codeship. Codeship can be accessed from the heroku resources page. All master changes should come from merging dev into master.

Staging Branch is what is deployed to staging. Code checked in to github staging branch will be deployed in the same way that master is deployed. Feature branches can be directly merged into staging in order to test out new features on the staging server before going live. You may force non-fast forward changes into staging if you want to test features which have not been fully merged yet.

Dev is where development should take place. Master should always track dev, nothing should be checked in to master without it being on dev. If you want to make a small change you can make it directly on dev, then merge it into master (when on the master branch, use the command git merge dev --no-ff). Larger changes should be made on feature branches and then merged into dev. Code checked in to github dev branch will be tested and pylinted, but not deployed.

Feature branches should be made for large changes where they can be worked on. Dev should be merged into them periodically as to not make merging it back to dev overly difficult when the time comes. They can be merged to staging to be tested on heroku. They can be merged into dev when completed, then merged to master form dev for deployment.

---

I think something like this might be useful: https://gist.github.com/leesmith/8441773