To Preproduction and beyond
Pre Production
Preprod Environments contain “real” data. This is generally a stale copy of production. As such anyone accessing these environments requires the appropriate level of clearance.
Promoting to preprod
In the new project under the helm_deploy directory you should see a file called values-dev.yaml. This contains overrides to helm deployment configuration for the dev namespace. Create a values-preprod.yaml file in the same format. For Kotlin template projects this needs overrides to the generic-service.replicaCount, the generic-service.ingress.host and the generic-prometheus-alerts.alertSeverity properties. For Typescript template projects copy values-dev.yaml and update all properties in the generic-service section.
If you look at the project in Github Action workflow .github/workflows/pipeline.yml you should see that the last step in the jobs is deploy_dev is currently uncommented. In .github/workflows/pipeline.yml you will see a big section commented out - this contains extra steps to deploy to preprod and prod. Uncomment deploy_preprod deployment step.
Once these changes have been made raise a PR and merge when reviewed. Your Github Action build post deploy to dev completion, should show request approval to deploy to preprod. Approve the preprod approval in Github actions workflow runs. Once deployed check that the deployment is healthy in a similar way to checking the dev deployment but replacing dev with preprod.
If you are creating a Typescript application you may still have a failing deployment. Make sure you create the same secrets in preprod that you created for dev.
Production
Production Environments contain “real” data. As such anyone accessing these environments requires the appropriate level of clearance.
Adding an external health check to prod
For production we use an external health check monitor called pingdom. This checks the application is up and can be reached from outside of our networks.
- In the
cloud-platform-environmentsproject add a pingdom health check for the application. Find another production namespace (e.g.hmpps-audit-prod) and copy fileresources/pingdom.tfinto your new directory. Update the name and change the url to match your certificate’sdnsName. - Add pingdom version details to the file
resources/versions.tf(copy an existing production namespace such ashmpps-audit-prod). - Raise a PR, ask in MOJ Slack channel
#ask-cloud-platformfor a review and merge when approved. - As we haven’t deployed to prod yet we should receive an alert from pingdom saying that the application is down. This proves that the pingdom check is working so wait for the alert before promoting to prod.
Promoting to prod
In the new project under the helm_deploy directory you should see a file called values-dev.yaml. This contains overrides to helm deployment configuration for the dev namespace. Create a values-prod.yaml file in the same format. For Kotlin template projects this needs overrides to the generic-service.replicaCount, the generic-service.ingress.host and the generic-prometheus-alerts.alertSeverity properties. For Typescript template projects copy values-dev.yaml and update all properties in the generic-service section.
If you look at the project in Github Action workflow .github/workflows/pipeline.yml you should see that the last step in the jobs is deploy_dev is currently uncommented. In .github/workflows/pipeline.yml you will see a big section commented out - this contains extra steps to deploy to prod. Uncomment deploy_prod deployment step.
Once these changes have been made raise a PR and merge when reviewed. Your Github Action build post deploy to prod/dev completion based on steps in cluded in jobs section, should show request approval to deploy to prod. Approve the prod approval in Github actions workflow runs. Once deployed check that the deployment is healthy in a similar way to checking the dev deployment but replacing dev with preprod.
Edit this page here.