Staged Continuous Deployment
Last updated: February 24, 2025
This page outlines the process that apps can use to deploy applications on their cadence, called staged continuous deployment. In addition to the daily production deployment, applications on the allow-list can take advantage of this method to have better control over their app’s updates. Changes to those applications are deployed to dev and staging on each merge to main upon successful completion of CI. Staged continuous deployment works similarly to the dev & staging deployments that are triggered for isolated application builds on the main branch. Only the bundles and chunks of the changed application(s) are updated in the S3 deployment buckets for staged continuous deployment.
Once staged continuous deployment is enabled for your application, the pipeline will pause after deploying to staging/dev for an approval. It is important to ensure that changes to your application are production ready, or behind a feature toggle, before approving this deployment.
Enabling staged continuous deployment
Staged continuous deployment is enabled by default for applications on the allow-list. By having an application on the allow-list with the required properties, the application will be opted in to continuous deployment.
{
"rootFolder": "vaos",
"slackGroup": "@vaos-fe-dev"
},Criteria for deployment
Before commits are deployed to production, both CI and the CD Production Deploy workflows perform a series of checks to ensure each commit is eligible for deployment in the workflow run. Commits are deployed to production if:
The commit contains changes solely to files in applications on the allow-list.
The changed applications all have staged continuous deployment enabled. (If any files are changed outside of an application that is approved, deploying directly to production will not be possible for that commit).
The commit is newer than the commit of the last completed daily production deploy.
The commit is newer than the commit being deployed in an in-progress daily production deploy. Otherwise, the daily production deploy will already contain the changes.
All applications are part of the daily production deploy, even if they have staged continuous deployment enabled. This means if your application has a deployment paused for review when the daily production deploy goes out, your changes will deploy as well.
Managing your application’s deployment
The process of managing your application’s deployment is no different from the process for managing failed isolated application pipelines, since all jobs in the CI pipeline must be successful in order for the commit to be deployed. To check if your commit was deployed to production, you can view the Deploy(vagovprod) job in the CI workflow run. If the production deployment was skipped, you will see that the deployment steps are skipped in the job.
Skipped deployment
The prior step Check if commit can be deployed should have logs with information about why the deployment was skipped.
Application owners are responsible for the staged continuous deployment of their applications, as opposed to the daily production deploy, where the Platform Team is responsible.
Approving your application’s deployment
Once your application has deployed to the staging and dev environments, a notice will appear in the #status-vets-website Slack channel to inform you that your application has a pending deployment.
Slack notice of pending deployment
Clicking the link will take you to the paused GitHub actions workflow where a member of the GitHub group fe-deployment-approval-team must approve the deployment. This is done by clicking on review deployments, checking the box for production, and clicking approve. The username of the approving party will be attached to the deployment.
Before deployment
After deployment
Once deployment has been completed, your changes should be available for viewing on the production site.
This puts changes immediately live to veterans without needing a daily deployment. All changes should be thoroughly reviewed on staging before any deployment is approved.
Rollbacks
If changes to your application need to be rolled back in production, you can do so by creating a pull request and merging it into main. There is no need for an out-of-band deployment, since changes to your application will be available to be approved for deployment automatically when the CI workflow run finishes successfully. You may then respond to the Slack notice as per usual with a deployment and approve the deploy to production.
Disabling staged continuous deployment
To disable staged continuous deployment for an application, the continuousDeployment property must be set to false for the application in the allow-list config:
{
"rootFolder": "vaos",
"slackGroup": "@vaos-fe-dev",
"continuousDeployment": false
},When opening a pull request for disabling staged continuous deployment, you should include a detailed reason of why you’re disabling staged continuous deployment for your application. Additionally, the product owner of the application must be added as a reviewer and approve the pull request.
By opting-out of continuous deployment, your application will no longer be able to be deployed to production on your own cadence. Applications opted out of continuous deployment will still be able to use existing features available to the allow-list, like the faster CI workflow pipeline, however, they will not have access to certain future features available to applications on the allow-list.
Help and feedback
Get help from the Platform Support Team in Slack.
Submit a feature idea to the Platform.