Reference‐Process‐&‐Workflow
Name your branches using this pattern: [nickname]/[issue#]-[meaningful-branch-name]
For example, atmos/123-fix-retirement-bug
Rebase your working branches every day with git pull --rebase origin staging. Rebase is preferred to merge as it makes commit-by-commit code-review easier.
PRs are squash-merged to staging, and staging is rebase-merged to main (no merge commits).
Use feature flags to keep PRs small and reviewable. It's OK to put unfinished UI on production, just flag it so it's hidden!
// import from app/featureFlags or site/featureFlags
import { features } from "lib/featureFlags"
export const Example = () => {
if (features.newFeatureFlagKey) {
return <NewFeature />
}
return <ExistingCode />
}Adding new feature flags to @klimadao/lib/featureFlags should be self-explanatory. Import them and use them to hide unfinished or untested UIs from production users.
When a PR is ready (after you have tested it thoroughly yourself!), QA and code-review can happen in parallel.
- Tag our QA manager and product managers as reviewer.
- Add the "QA needed" label to the PR.
- Tag other code reviewers
The QA manager will add any findings as PR review comments. When the QA manager believes it is production ready, they set the label to "QA done"
Do not make changes to package.json or package-lock.json in any other PR.
This section offers an overview so we are aligned on what options there are for fixing urgent issues on production. If the issue is not in production, or not urgent, just put up a PR
A1. Major, minor, patch release
v2.0.0 ⇒ v2.1.0
A2. Hotfix to existing version release
Redeploy code from a branch to repair a specific version of the API.
v2.0.0 ⇒ v2.0.0
A3. Canary API release
Create a branch with a new release for immediate consumption.
This is useful if you need the fix but aren’t ready to support the version long term.
I.e. v2.0.0 ⇒ v2.0.0-beta1
A4. Branching hotfix
Same as above, it is also possible to branch off and deploy from earlier versions of the API.
v1.2.0 ⇒ v1.2.0-hotfix1
A5. Vercel rollback or git commit revert
Be careful if the API has already been released to the public. I can’t think of a specific situation when this would be the preferred fix, so use your best discretion.
F1. Vercel rollback
Immediately put production UI back to the last known working version.
F2. Git commit rollback
Add a revert commit to remove the offending commit before the next daily release, otherwise your Vercel rollback will be undone.
F3. Expedited release
Admins can trigger the “Schedule Auto Merge” action to put all staging code on production at any time. This is scheduled to run every weekday.
-
git bisectis a tool that all developers should know how to use, to identify exactly which commit needs to be reverted. - https://semver.org/