GitHub Actions (for vets-website and content-build) and Jenkins (for vets-api) perform the following tasks after a pull request is merged into
mainbranch to create a deployment artifact (.tar file)
Deploy to development and staging using deployment artifact
in GitHub from main, tag artifacts of that commit SHA hash with release name
Deploy to production using deployment artifact according to automated deployment schedule
A big assumption in this process is that the
main branch should always be deployable. As such, the deployment to the staging environment is configured to happen automatically and can be used to see what something would look like in a production-like environment for any kind of manual testing/verification.
Automated deployment schedule
All listed times are eastern timezone and are scheduled Monday–Friday (excluding holidays). All deployments are executed from the main branch in each repository.
View the Frontend Dashboard to see the deployment status of a commit.
Changes in by
GitHub Action Workflow/Jenkins Job
content-build (content only)
9am–12pm Hourly, 1:45pm, 4pm, 5pm ET
Automated process details
The Daily Production Deploy workflow in vets-website has several jobs that run, primarily including the
Create Release job, which tags the release for production, and the
Deploy job, which deploys the release artifact
The Daily Production Release workflow in content-build only tags the release. The next Content Release workflow that runs will use the latest release.
These jobs should not be triggered manually.
If a production deployment introduces issues that affect Service Level Objectives (SLOs) established for the project, you may restore service to users by rolling back to a previous deployment. This is accomplished by triggering a new Daily Production Deploy workflow in GitHub Actions using a previous release tag. Typical deployment times are under 5mins.
Click on the commit ID in the left column of the release you want to reference
Copy the commit ref (it will be a long string like:
At the top of the previous workflow runs, click “Run workflow”
Enter the ref value into the “Deploy specific commit” field
Click "Run workflow"
If SLOs are not affected and a fix is not critical, no rollback will be issued. Instead the fix should be applied through the standard development workflow.
In addition to the daily production deploy, certain applications in
vets-website can be deployed to production via continuous deployment. Applications on the allow-list are also deployed to production when changes to the application are merged into
main and the CI workflow run for the commit is successful. To learn more about continuous deployment, see the documentation on continuous deployment.
Feedback and support
Create an issue to suggest changes to this page.
Questions? Request help in Slack.
Sign up for the Platform newsletter to get monthly updates on new features and changes.