Contributing to a codebase

Having a seamless and reliable deployment pipeline is crucial for rapid development. We use a git-based feature branch workflow together with CircleCI and Heroku flow. This allows us to deploy well-tested code to production multiple times a day.

When contributing to the codebase, it's important to follow the conventions of the organisation as well as those particular to the project itself. Everything from creating descriptive commit messages to notifying the right person at the right time will result in a better development experience for yourself and others.

Developer

• Creates a local feature branch based off master using a consistent naming convention

• When feature is complete and tests pass, commits the changes with a good commit message

• Pushes their branch to the remote

• Submits a pull request (PR)

• Adds the corresponding issue # in the PR description using GitHub keywords such as "Fixes", "Closes", "Resolves"

• A Heroku Review App will be generated

• Requests a code review by assigning someone as a reviewer

• Addresses any of the requested changes or feedback provided by the reviewer

• Read: Google Engineering Practices

Code reviewer (Systems architect)

• Reviews the code on the branch, adhering to the code review guidelines

• If there are any changes required, requests them

• Once it looks ready, approves the PR

• Assigns the PR to the QA

Quality Assurance (QA)

• Tests the Review App generated by Heroku

• Adds either a QA passed or QA failed label to the PR.

• If QA failed label is attached, assigns the PR back to the author

• Once QA passed label is attached - Merges PR.

If the issue # is linked in the description, this will automatically close the issue and notify the PM

NB: Any merges into master are automatically deployed to a Heroku staging app

• Deletes the branch

Product Manager (PM)

• Checks the Heroku staging app is working as intended

• Updates the issue with any additional information, if required

• Promotes to live when ready