HOLD on:
Problem
While we have a robust QA process ingrained into the NewDot deploy cycle, and we try to maintain a high standard of code development, we still make mistakes and introduce bugs to production.
However, when NewDot bugs exist on production, we currently have several suboptimal options to fix those bugs:
Wait for QA to complete on staging, fix all deploy blockers, and ship staging to production. This option is not ideal because it can oftentimes take multiple days, during which time the issues on production are not fixed.
Following this StackOverflow, manually open a PR against the production branch, bump the version, and have ring0 merge that PR. This option is not ideal because code is manually edited on the production branch without being tested on staging first, and it requires input from ring0, meaning it cannot be done by mobile-deployers alone.
Ultimately this problem is important to solve because we feel we need better options to handle issues in production. We want to avoid a scenario where we don’t fix issues on production for multiple days waiting for the normal staging deploy and QA process, or make a bad situation worse by making breaking changes on production and drawing Ring0 time to address issues.
Solution
Update cherryPick.yml to support cherry-picking PRs to production.
HOLD on:
Problem
While we have a robust QA process ingrained into the NewDot deploy cycle, and we try to maintain a high standard of code development, we still make mistakes and introduce bugs to production.
However, when NewDot bugs exist on production, we currently have several suboptimal options to fix those bugs:
Wait for QA to complete on staging, fix all deploy blockers, and ship staging to production. This option is not ideal because it can oftentimes take multiple days, during which time the issues on production are not fixed.
Following this StackOverflow, manually open a PR against the production branch, bump the version, and have ring0 merge that PR. This option is not ideal because code is manually edited on the production branch without being tested on staging first, and it requires input from ring0, meaning it cannot be done by mobile-deployers alone.
Ultimately this problem is important to solve because we feel we need better options to handle issues in production. We want to avoid a scenario where we don’t fix issues on production for multiple days waiting for the normal staging deploy and QA process, or make a bad situation worse by making breaking changes on production and drawing Ring0 time to address issues.
Solution
Update
cherryPick.ymlto support cherry-picking PRs to production.