Skip to content

Milo Contribution Process

Okan Sahin edited this page Nov 13, 2024 · 12 revisions

Contributing. Your guide from branch to stage to production

To start out with, you should be reading the wiki on submitting PRs & there is a lengthy discussion about the stage process we have implemented as well as an announcement from the milo core team.

Let's highlight the most important aspects here:

Getting your code to production

  • Devs: open PR, 2 developer approvals, green light from PM & Consonant on the PR/Jira as needed, all Github checks pass, assign QE
  • QE: apply "Ready for Stage" label after testing
  • If the conditions ☝️ pass (reviews, checks, label) the PR will automatically be queued to be merged into Stage
  • Once a stage "batch" PR gets created, the batch gets merged on India/EU/US working hours once 4 SOT sign offs are provided & checks are passing

Note: The "queue" is not obvious, but you can investigate the most recent workflow runs to see why your PR was merged or not. If still unsure, reach out to #milo-dev

Fixing prod bugs

  • Bug on prod: Open PR to revert PR or batch and restart at "Getting your code to production"

CSO

  1. Create a revert and raise PR-1 from main
  2. Test on PR-1's branch and get QE sign-off
  3. PR-1 should go as 'merge' commit into main
  4. Checkout a new branch based on stage
  5. Cherry-pick the commit(s) from PR-1
  6. Open a revert to stage PR-2
  7. Merge PR-2 into stage

Note: Given the commit hash differences, merging stage into main might include the changes in the diff and merge the extra commit from stage into main, but this can safely be ignored

Allowing for exceptions

There is an ongoing discussion which we'd love you to chime in on

PR Labels

  • Every PR must be tested. QE should apply the 'Ready for Stage' label only after a PR has received approvals, all checks have passed, and testing is complete.
  • The 'high impact' label will trigger a message in #milo-community & #milo-changelog for PRs that require additional review from consumers, GWP, design, etc.
  • The 'high priority' label will prioritize PRs in the merge queue. Please reserve this label for JIRA BLOCKERS only.