Development Process

Get a local working copy and make sure you have secrets.py set up appropriately if you are using a snapshot of the production database.

When working on anything, start by creating a git branch for the work. It is entirely up to you if you push this branch to the GitHub repo but if you do, use a decent name. Only push the work branch to the repo if you need to share it.

(cccs)~/wk/cccs/core $ git branch -b issue-666

When you are ready to share your work, begin by dropping it into the ci branch (first bringing that branch up to date):

(cccs)~/wk/cccs/core $ git checkout ci
...
(cccs)~/wk/cccs/core $ git pull
(cccs)~/wk/cccs/core $ # Sometimes you may need to merge master in to bring hotfixes in to ci
(cccs)~/wk/cccs/core $ git merge issue-666
...
(cccs)~/wk/cccs/core $ git push

This will automatically update ci..com through jenkins so your changes can be reviewed.

note: we'll have tests and test reports associated with the ci at some point but currently it just builds and deploys the site.

Assuming your changes are looking good to development, you next submit them for approval into master by merging them into the staging branch.

(cccs)~/wk/cccs/core $ git checkout staging
...
(cccs)~/wk/cccs/core $ git pull
(cccs)~/wk/cccs/core $ # Sometimes you may need to merge master in to bring hotfixes in to staging
(cccs)~/wk/cccs/core $ git merge issue-666
...
(cccs)~/wk/cccs/core $ git push

Staging is currently manually deployed so you'd then assign the relevant issue to whoever deploys staging and tell them to deploy it.

It is then out of your hands...

The dev responsible for staging will deploy staging (with your fix and possibly a bunch of others). If staging is approved by management, it will then be merged into master and deployed to the live site.

Both staging and ci use snapshots of the live database. These snapshots are updated whenever the sites are redeployed so that any data model changes and migrations are tested.