Before deploying any new changes, it is essential to conduct thorough pre-deployment checks to minimise the risk of issues and ensure a successful deployment. This document outlines the recommended checks to be performed before initiating the deployment process.
Please find the recommended checks for Code-only deployments below:
Platform/Infrastructure level:
- Disk Usage: The disk usage for the node(s), and ensure if the node(s) is not at greater than 85% disk space utilisation
- The Memory and CPU consumption - Assess the memory and CPU consumption to ensure optimal performance.
- The Load average - Monitor the load average to maintain system stability
All of the above checks can be done by obtaining the information from the Metrics tab of the stack environment, and if you find anything abnormal/wrong, please reach out to us by raising a service desk ticket.
Application level:
- When deploying on the production environment, consider restoring the Production Database snapshot on the UAT environment. Initiate the release deployment on UAT beforehand to verify compatibility with the Production Database. This step helps ensure a seamless deployment and identifies any potential issues before applying changes to the live production environment. Please compare UAT and PROD stack sizes as this can lead to different behaviour of the 2 environments - especially if restoring a Prod DB.
- composer install:Deployment may fail during the composer install phase if a third-party repository is inaccessible or if the environment lacks the necessary permissions. If such issues arise, ensure the repository is available and permissions are configured correctly.
- dev/build: Failures during the dev/build process may result from improper object creation due to existing data issues. Addressing these issues and ensuring proper data setup can help prevent deployment obstacles.
- yarn cloud-build: Failures in yarn cloud-build are often linked to node environment problems. For instance, a dependency might require a higher version than currently available. To mitigate such issues, consider testing cloud-build script with the platform specifications. Please find the available versions here: https://nodejs.org/en.
- One deploy key for multiple repositories: Once the deploy key is added in the primary repo, you will need to go to the 'Privately accessible Deploy keys' section and enable it for the other Repo/Project as the key is already in the list. This would create a similar link between the projects.
Please find the recommended checks for Full deployments below:
- .htaccess: Sometimes the rules in .htaccess will prevent the “host.txt” from being accessed. Some of the rules in this .htaccess file causes a redirect when load balancer attempted to access “host.txt” file under the website root directory .../mysite/www and resulted in a 301 status code. This causes the load balancer health checks to fail, and eventually the deployment get failed.
- .platform.yml: Issues may arise if the .platform.yml file is incorrectly named (misspelled) or if its contents deviate from the correct syntax. As a precautionary measure, it is recommended to conduct a thorough cross-check of the .platform.yml file. Ensuring the accurate naming and syntax adherence of the file is crucial to prevent deployment complications.
- Checking the system as a whole, making sure existing functionality is working as expected.
- Environment variables: Ensure that both the names and the values of the environment variables are in the correct format and doesn't include any extra spaces.