The process of review, test, merge and deploy
The Open Food Network has many contributors around the world. Everybody is working on different code and still we want to merge it all together into the
master branch at Github.
A core development team currently oversees all contributions to the master branch. A pull request goes through the following stages:
1. Change & Submit
Have a look at our CONTRIBUTING.md for more information about picking up an issue, making changes to the codebase and submitting a PR.
Pull requests need to be reviewed and approved by at least one member of the core development team before progressing to the review stage. Reviews from other contributors are very welcome. Reviewers may request that changes be made to the pull request. Changes should be added in separate commits, one for each issue pointed out during the review. Some of the added commits may be squashed to remove dev detours from the history (see Making a great commit). Once a pull request has been approved it can progress to the test stage.
Most pull requests will require some user testing. Very small or non-functional changes may move to the merge stage directly, at the discretion of the core dev reviewer.
If user testing is required, this should occur in a context that resembles a production environment as closely as possible. Generally this will mean a staging server that is configured similarly to production and that contains production-like data. Once deployed, the changes made by the pull request should be tested by a person who is neither the developer nor the last reviewer. The pull request should contain enough information to determine what to look for and what should be tested.
The person responsible for testing should provide a clear pass/fail with a very brief summary as a comment on the pull request. A link to more detailed testing notes should also be provided. These notes should ideally be created in a public Google Doc or similar shared document in the public domain.
See more detailed testing process here.
4. Merge & Deploy
Pull requests should be reviewed by at least two members of the core team before being merged, except for non-code PRs like a change to the readme file. If everybody is happy with the pull request, it can be merged into the master branch and deployed to a production server.
It is important that each new addition to the
master branch is deployed to a production server immediately. This helps to ensure that the
master branch is production ready at all times.
If the team responsible for testing and merging doesn't feel confident doing in deploying the code to a production server, then the code should not be merged and they should delegate responsibility for merging to another team.