Silverstripe Cloud may opt to perform different types of deployments depending on a number of factors, some of which you can control directly.
Full deployments
If any non-code changes need to be applied to your environment Silverstripe Cloud will automatically force a “full” deployment.
In this scenario the virtual machines are rebuilt from scratch which opens up an opportunity to change the operating system, apply security patches, install packages, update configuration, and restart services.
Full deployment consists of the following actions (order may vary depending on your environment type):
- virtual machine build
- code deployment, running “dev/build”, and flush
- cycling the new machines into running environments
Code-only deployments
If the only change that needs to be applied to your environment project code change, Silverstripe Cloud will elect to do a “code-only” deployment.
This deployment is much faster, as it will only deploy code, run “dev/build”, and flush.
When is a full deployment needed
Silverstripe Cloud surfaces the changes made to your .platform.yml as line items in the deployment plan. If anything needs to change other than the “Code version”, a full deployment will be made.
There are situations however when a full deployment will be made even though no changes seem to be needed.
In most cases this will occur because of:
- your request for making changes to the environment variables
- your request for other customisations of the environment, such as applying whitelists, installing additional PHP modules or increasing PHP memory limits
- our tweaks to improve stability of your environment, such as changes to search engine robot handling.
If you are unsure why a full deployment is required please contact the Service Desk.
Note: The dev/build logs will only be visible in the deployment logs if the deployment fails at the dev/build stage.
Failures & rollbacks
In case of failures Silverstripe Cloud will attempt to gracefully recover your environment. There are three kinds of failures that can occur during a deployment:
- virtual machine build failure (full deploy only)
- dev/build failure (DB migration problem)
- smoketest failure (site not responding, possibly due to code error)
Full deployments
Initial virtual machine builds are performed in sandboxed environments and failures during that stage will not impact running environments. The faulty machines are terminated and the deployment aborted.
Handling of “dev/build” and smoketest failures during a full deployment depends on your environment size.
On larger, scalable environments, the new machines are put into the target environment tentatively. Only after they report healthy the originals are removed. Failures at this stage will not affect your website as in most cases the new machines can be removed from the environment without affecting the originals.
On non-scalable stacks (such as solo) there is no opportunity to run original and new machines side by side. Failures during the “dev/build” and smoketesting always require a rollback to the previous working version. Outage duration is shortened by preserving the original machines so that the lengthy machine build step can be skipped.
Code-only deployments
Code-only deployment failures always trigger a rollback to previous code revision.