Skip to main content
Skip table of contents

Deployment Policies

Last Updated: April 14, 2025

Deployment Strategy

We intend to keep our repositories always deployable from the primary branch. The deployment schedule below describes when deployments typically happen, but deployments from the primary branch may occur at any time. VA.gov does not use release branches; instead, we maintain a focus on keeping the primary branch healthy.

For finer control over when your checked-in feature is released, see Feature toggles guide.

Automated Deploys

See schedule here: https://depo-platform-documentation.scrollhelp.site/developer-docs/deployments

Exceptions to automated deploys

If there are days or periods of time when many people will be out of the office (i.e. holidays) the automated deploys will be suspended. If people aren’t in the office to support the code going out, it’s not responsible to release.

Note: This only applies to automated deploys. Engineer-initiated deploys (e.g. to address a critical bug) will be allowed to proceed as usual.

Holiday production release freeze schedule

During holiday release freezes:

  • Automated deployments to production and sandbox environments will not occur.

  • Teams can still continue to merge code to main or master branches. This will continue to be deployed through development and staging environments during the release freeze time frame.

  • All prod deploys require approval via the "Requesting out-of-band-deploys" process below.

  • Content-only deploys will continue as normal, but support will be limited.

  • Limited support will be available from the Platform team.

There may be a change in this policy as VA dictates.

The holiday production release freeze is in effect during the following dates:

2026

  • 1/19/2026 – Martin Luther King Jr. Day

  • 5/25/2026 – Memorial Day

  • 6/19/2026 – Juneteenth

  • 7/3/2026 – Independence Day (observed - July 4 is a Saturday)

  • 9/7/2026 – Labor Day

  • 11/11/2026 – Veterans Day

  • 11/26/2026 – 11/27/2026 – Thanksgiving

  • 12/21/2026 – 1/4/2027 – Holiday Freeze (prod deploys resume on 1/4)

Requesting out-of-band deploys

If there is a critical issue that needs to be resolved outside the automated deployment schedule, explicit permission must be granted for an out-of-band deploy.

Open an OOB Deploy Request Issue Ticket and verify each of the tasks.

For recommended approaches to issue resolution (i.e. when to revert, when to fix forward), see Resolving critical issues. 

For every out-of-band deploy requested, the Platform team will expect a follow-up postmortem from the requesting team, explaining the context that led to the problem and proposing follow-up actions to prevent similar future problems.

Is my issue critical?

Examples of critical issues include:

  • A bug that’s preventing a significant number of Veterans from accessing a feature

  • A bug creating a non-trivial deviation from expected functionality

  • A 508/accessibility failure of severity level 0 (Showstopper) or 1 (Critical) (severity rubric)

Examples of non-critical issues include:

  • Incorrect text or visual formatting that does not impede the feature from working

  • Any code for features not yet released to Veterans

  • Just wanting to get code out sooner

When in doubt on whether an issue is critical enough for out-of-band deployment, OCTO-DE leadership for the Platform will decide.

Step-by-step process for Out-of-Band (OOB) deployment approval

Out-of-Band (OOB) deployments are reserved for emergency situations that require immediate action and cannot wait for the standard deployment window.

Standard Process

1. Open a Support Request

  • In #vfs-platform-support, run /support

  • In the form:

    • Request topic: Select Out-of-Band Deployment

    • Summary of request: Include:

      • Summary of the issue

      • Severity

      • User impact (must include estimated number of users affected)

2. Assign Ownership

  • Assign the request to the appropriate team (Frontend, Backend, DevOps, etc. if known)

3. Create Deployment Request

4. Approval

  • Tier 1 assesses the issue and triggers PagerDuty (/pd trigger) if escalation is required. This notifies OCTO-DE Platform staff needed for approval.

  • The deployment must be approved (or declined) by OCTO-DE Platform staff before proceeding.

5. Deploy

  • Platform Support performs the deployment once approved

6. Postmortem

  • Within two business days of this incident open a PR with a postmortem using this template and with the steps outlined in the included README.md.

After Hours / Weekend Process

For OOB requests after 5pm ET on weekdays, weekends, or holidays:

  • Follow the same steps as above, with the following requirements:

    • Email incidentcommander@ecc.pagerduty.com before any escalation

    • Tier 1 determines if PagerDuty should be triggered based on severity and urgency

    • If escalation is required, trigger PagerDuty after assessment

    • Clearly indicate in the request that this is an OOB emergency after hours

    • Be prepared to coordinate with on-call OCTO-DE Platform staff

Off Hours Deploy (OHD) – Planned Deployment

There are instances where teams require a deployment outside of the normal deployment window, but the request does not qualify as an Out-of-Band (OOB) deployment. These deployments often require additional attention or carry higher risk, making them unsuitable for the standard deploy process.

Off Hours Deploy (OHD) is intended for planned, non-urgent deployments that need to occur outside normal deploy windows. These requests should be submitted in advance to ensure proper coordination, reduce risk, and confirm the appropriate support is available.

OHD is not the same as OOB.
If the request is urgent or tied to an incident, follow the OOB process instead..

Steps to Submit an Off Hours Deploy Request

  1. Initiate the Request

    • Create a Support Ticket in the #vfs-platform-support Slack Channel, using the “Off Hours Deployment” Request Topic.

  2. Fill Out the Ticket Template

    • Open an OHD Request Issue Ticket and verify each of the tasks:

      • Description and Expectations: Outline what is being deployed and any specific goals.

      • Requesting Team: Identify the person and team making the request.

      • Date and Time: Specify the requested deploy date and time.

      • Platform Maintenance Window: Indicate if the deploy should be tied to a Platform Maintenance Window. If so, note the specific window.

      • Justification: Provide a reason for why this deploy cannot be handled within the daily deploy window or an OOB deploy.

      • Potential Support Needed: List any necessary support (e.g., Backend, Frontend, DevOps).

  3. Coordination and Awareness

    • Once the OHD Request Ticket is complete, Tier 1 will engage by:

      • Ensuring team members are aligned with the proposed date and time.

      • Confirming the timing does not overlap with an existing Platform Maintenance Window (if applicable).

      • Assigning the request to the correct Support team as well as the specific T1 and T2 on-call person.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close