This document contains basic instructions for the maintainers of the DEV application. It's a work in-progress, but should allow the DEV Core Team to document processes and strategies in a transparent way!
Some small PRs might seem like good candidates for skipping the CI suite. For example, a change that only touches documentation copy or a tiny CSS tweak.
For the time being, we should avoid skipping CI in PRs because it causes some confusion during the review process. However, it does make sense to skip CI on merge commits that include extremely minor changes.
You can skip CI by appending [ci skip] to merge commit's message.
When in doubt, don't skip CI.
At the moment, our PR review process is being evaluated, so this is subject to change.
Before a PR is merged we expect:
PR review is the Core Team's opportunity to weigh-in on changes before they go into master.
Keep in mind that our team is distributed across the world. It's a good idea to leave far-reaching PRs open for a day, to give everyone a change to share their thoughts.
At the time of writing, we tend to prefer squashing PRs into a single commit and merging them. This is easily (and safely) achieved using the GitHub UI.
If the application needs to be deployed when the code is merged, appending [deploy] to the merge commit's message will trigger a deploy.
Generally, it's a good idea to keep the SRE team in the loop on any deploys.