Skip to main content

Recutting a Release Candidate

Guidance for Experience Teams: Requesting an Updated Release Candidate (RC)​

Default Policy: Catch the Next Train​

Because the Mobile Platform operates on a strict, regular release cadence (new RC builds are cut from develop multiple times a month), the default action for any issue found after an RC is cut is to fix it and release it in the following cycle.

Requesting a re-cut of the current Release Candidate is highly disruptive to the QA regression testing process and the overall release schedule. Re-cutting a Release Candidate introduces significant risks to the app, app platform, and the Veteran users. It can also lead to a cascade of other issues, throw-away work, and impact the standard release schedule moving forward.

Therefore, re-cuts and other out-of-band deployments are exceptionally rare.

Strict Qualifications for an RC Re-cut​

To warrant an RC re-cut, the issue must present an immediate, unacceptable risk to Veterans. The Mobile Platform Team will only entertain a re-cut under the following circumstances:

  1. Sev-1 (Critical) Regressions with No Workaround:
    • High Impact + High Frequency: The bug prevents task completion, causes a hard crash, or corrupts data in a workflow used by >15% of monthly users (e.g., Login/Auth, Home screen, Claims, Rx Refill, Secure Messaging).
    • No Mitigation: There is no viable workaround for the Veteran to achieve their goal while we wait for the next release/there is no way to clearly communicate alternative direction to the Veteran.
  2. Critical Security or Privacy Vulnerabilities: An issue that compromises PII/PHI or violates VA security protocols.
  3. External Mandates: A strict, non-negotiable legal or compliance mandate (e.g., a directive from Congress or VA Leadership) that requires immediate code delivery before the next scheduled release cycle.

What Does Not Warrant a Re-cut​

To preserve the release cadence, the following scenarios should default to the next release cycle:

  • Sev-2 (High) or Sev-3 (Low) Bugs: Unless they carry extreme business risk approved by Leadership.
  • Missing or Untested Code: Merging untested code or realizing code missed the branch cutoff does not justify a re-cut unless its absence triggers a Sev-1 critical failure.
  • User Experience/Styling Issues: Even severe UX issues should wait for the next release unless they completely block task completion (becoming a Sev-1).

Requirements for Submission​

If your team believes an issue meets the criteria above, you must reach out to the Mobile App Platform Team and its POs to make a request. The request must detail:

  1. The Unacceptable Impact: A thorough explanation of the business or user impact if the current build goes live without the change (proving it is a Sev-1).
  2. Approvals: Confirmation that the Product Owner (PO) has approved the emergency change and the Release Team has been notified.
  3. QA Reset Strategy: Acknowledgment of whether QA's initial RC testing was completed, and a defined test strategy to safely verify the new RC branch without blindly delaying the release cadence.