Development Process

You are going to fix an issue or make some sort of enhancement to the code...

Understand Git well (at least read the first three chapters of Pro Git) before you go any further. It will make you more productive.

Our master branch is fully working code that is generally on the production site or sites. We also typically have a staging branch for fully working code that is awaiting approval for merging with master and a ci branch containing code that devs think is working and that they believe is worth merging into staging. Thus ci is usually working, staging is always working and master is most definitely always working. If ci is not working, we're fixing it as a high priority. If staging is not working, we generally revert it and try again later so it is never not working for long. If master is not working, we're in panic mode trying to fix it (almost certainly by reverting).

Merges into master are usually only done by @pwhipp or @cccs-web/owners from staging. devs generally only merge into staging after some sort of approval (judicious abuse of this privilege is tolerable but risks the dev ceasing to be a dev if it goes wrong).

[Get a local working copy | Installation] and make sure you have secrets.py set up appropriately.

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 release 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 (currently @pwhipp) 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.