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. https://va.gov does not use release branches; instead, we maintain a focus on keeping the primary branch healthy.
There are automated deploys of
vets-website Monday through Friday. The release is created from the primary branch at 2 pm Eastern and deployed at 3 pm Eastern. Code merged to the primary branch after 2 pm Eastern will not be added to a release and deployed until the next business day.
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 release freeze schedule
During holiday release freezes:
Automated deploys will not occur
All code deploys require approval via the "Requesting out-of-band-deploys" process below
Content-only deploys may continue without explicit approval, but need to be manually triggered
Limited support will be available from the Platform team.
There may be a change in this policy as VA dictates.
The holiday release freeze is in effect during the following dates:
05/30 - Memorial Day
6/20 - Juneteenth (observed)
07/04 - Independence Day (observed)
09/05 - Labor Day
11/11 - Veteran's Day
11/24 - 11/27 - Thanksgiving (note: weekend included for clarity)
12/24 - 1/2/2022 - Winter holiday freeze (note: weekends included for clarity)
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 deployment approval
Open a support request in #vfs-platform-support using
Assign to the team who manages the code needing deployment (Release Tools, Console Service Team, etc).
Select “Off-Cycle Deployment“ for the nature of the request
Include a summary of the issue, severity, and user impact
User impact should include the number of users affected.
Platform support staff triggers PagerDuty using
/pd trigger. This will notify the relevant OCTO-DE Platform staff which is required for the next step
Select “Out-of-band Deployment (service).
Leave “Assign to” blank
Put the summary, severity, and user impact from the Slack support ticket in the description, as well as a link to the #vfs-platform-support Slack thread.
The deployment request must be approved (or declined) by OCTO-DE Platform staff before it may proceed.
If approved, the Platform support staff will perform the deploy.