-
Notifications
You must be signed in to change notification settings - Fork 0
Recommended Protocols and Best Practices
We recommend that all contributors to the Colouring Platform follow the guidelines below, in order to minimise mistakes and errors, and to follow Software Engineering Best Practices.
We recommend that the primarily branch (usually "main" or "master") is protected using the branch protection rules provided by GitHub. It should not be possible to push changes directly to this branch, as this is considered the active branch - the working version of the code that will be deployed to the server.
Pull Requests should be required to merge changes onto this branch and, where possible, the pull request should be reviewed by another member of the Colouring Cities technical team before merging. A second pair of eyes can help catch any errors, debug outputs and other issues before they are deployed.
Also, please fill in the Pull Request description with as much detail as possible.
Any changes to the platform should be thoroughly tested before they are deployed. There should be multiple layers of testing in order to minimise incorrect and erroneous code making it into production versions of the platform.
- Local Testing - The engineer should have a local version of the site (i.e. running on a VM on their computer), which they can use to test new features. They can share their screen during a Zoom/Teams call to get feedback on the changes from other members of the CCRP.
- Staging - Colouring Britain has two servers. One is a smaller, less powerful (and less expensive) VM, which is used as a Staging or testing site. Changes (including from in-development branches) can be deployed to this Staging site, so the PI can see and interact with these changes and then report any bugs or request changes before the updated code is merged into the master branch.
- Production - The 2nd Colouring Britain server is the Production server. This is the VM that hosts the production version of the website (i.e. https://colouringbritain.org/). Only code that has been thoroughly tested by the engineer, PI and other stakeholders via the methods described above.
We also recommend that, whenever changes are merged onto the main/master branch, that they are thoroughly tested before deployment to production.