Continuous deployment
In addition to the daily production deployment, applications on the allow-list can enable continuous deployment. Changes to those applications are deployed to production on each merge to main upon successful completion of CI. 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 continuous deployment.
Once continuous deployment is enabled for your application, it is important to ensure that changes to your application that are merged into main are production ready, or behind a feature toggle.
Enabling continuous deployment
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, CI performs 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 continuous deployment enabled.
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 continuous deployment enabled.
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 continuous deployment of their applications, as opposed to the daily production deploy, where the Release Tools Team is responsible.
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 automatically deployed to production once the CI workflow run finishes successfully.
Disabling continuous deployment
To disable 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 continuous deployment, you should include a detailed reason of why you’re disabling 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 deployed to production when changes are merged to main. 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.